Gitea OAuth2 userinfo private group disclosure to public-only tokens
Affects Gitea 1.23.0 through 28.3.0 when a public-only OAuth2 token is sent as a query parameter, exposing private organisation and team names in the userinfo groups claim. Fixed in 28.3.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 8/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 28.3.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Gitea, the self-hosted Git service, is affected through its OAuth2 userinfo endpoint. A caller holding a public-only token could see the names of the token owner's private organizations, teams, and hidden memberships, though no repository content was exposed.
Read the original description
The OAuth2 userinfo endpoint (`/login/oauth/userinfo`) decided whether to limit the `groups` claim to public organizations by re-parsing the `Authorization` header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships. The disclosure is limited to the owner's organization and team names and memberships; no repository content is exposed. The endpoint now uses the scope of the authenticating token.
What to do
Check whether your setup matches what the bug needs.
Gitea accepts the access token as a query parameter by default The token is a public-only OAuth2 token sent as a query parameterUpgrade to a fixed version: 28.3.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- gitea.dev
From 1.23.0 · fixed in 28.3.0
Evidence 5
- Advisory
- Patch
- Patch
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-118394
What does this mean?
A public-only OAuth2 token sent as a query parameter also receives the names of the private organisations and teams the user belongs to, in the groups claim. The advisory says this exposes organisational structure, not repository contents or credentials.Source: github.com, blog.gitea.com
Am I affected, and how do I check?
Gitea 1.23.0 up to but not including 28.3.0. The issue requires an OAuth2 token passed as a query parameter, which Gitea accepts by default; the version can be checked with the gitea --version command on the server.Source: github.com, blog.gitea.com
What should I do about it?
Upgrade Gitea to 28.3.0 or later, which contains the fix.Source: github.com, blog.gitea.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data