Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
A valid API token is required (PR:L, not PR:N); disclosure is limited to the holder's own email and group membership (C:L), with no integrity or availability impact.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
Lifecycle Timeline
5DescriptionCVE.org
Summary
The OIDC userinfo endpoint (GET /login/oauth/userinfo) accepts Gitea API tokens as bearer credentials but does not enforce API token scopes before returning identity claims.
A personal access token scoped only to read:misc can successfully retrieve user information from the OIDC userinfo endpoint, even though the same token is denied access to user-related REST API endpoints that enforce scope checks.
As a result, identity information remains accessible through the OIDC endpoint regardless of the scopes assigned to the API token.
Details
Gitea supports scoped personal access tokens and enforces scope checks on user-related REST API endpoints.
For example, a token scoped only to read:misc is denied access to endpoints such as:
| Endpoint | Required Scope |
|---|---|
GET /api/v1/user | read:user |
GET /api/v1/user/emails | read:user |
GET /api/v1/user/orgs | read:organization |
Requests to these endpoints return:
403 Forbiddenwith a scope-related error.
However, the same read:misc token can be supplied as a bearer credential to:
GET /login/oauth/userinfo
Authorization: Bearer <token>and receives a successful response containing identity claims.
Observed claims include:
emailgroups
The groups claim contains organization and team membership information associated with the authenticated user.
This behavior indicates that the OIDC userinfo endpoint accepts API tokens but does not apply scope restrictions before returning identity claims.
PoC
PoC Details
Proof-of-concept code: https://anonymous.4open.science/r/Gitea_PoC-EC93/3_poc_oidc_userinfo_scope_bypass
Reproduction Steps
- Create a personal access token with only the following scope:
read:misc- Verify that the token cannot access user-related REST API endpoints:
GET /api/v1/user
GET /api/v1/user/emails
GET /api/v1/user/orgsEach request returns:
403 Forbidden- Send the same token to the OIDC userinfo endpoint:
GET /login/oauth/userinfo
Authorization: Bearer <read-misc-token>- Observe that the request succeeds and returns identity claims, for example:
{
"email": "user@example.com",
"groups": [
...
]
}Impact
Holders of narrowly scoped API tokens can obtain identity information through the OIDC userinfo endpoint regardless of the scopes assigned to the token.
The issue does not provide access to repositories, issues, pull requests, administrative functionality, or data belonging to other users.
Impact is limited to disclosure of identity information associated with the authenticated user. However, it weakens the authorization boundary established by API token scopes because identity claims remain accessible even when the token lacks user- or organization-related scopes.
AnalysisAI
Identity-claim disclosure in Gitea (self-hosted Git server) before 1.27.0 lets any holder of a valid personal access token retrieve their email and organization/team membership from the OIDC userinfo endpoint (GET /login/oauth/userinfo) even when the token's scopes (e.g. only read:misc) would deny the equivalent REST API calls. The endpoint accepts API tokens as bearer credentials but skips the scope enforcement applied elsewhere, collapsing the authorization boundary that scoped tokens are meant to provide. Publicly available exploit code exists; the flaw is not in CISA KEV and EPSS is low (0.17%).
Technical ContextAI
Gitea implements OAuth2/OIDC and issues scoped personal access tokens (PATs) whose scopes (read:user, read:organization, read:misc, etc.) gate the v1 REST API. The OIDC userinfo endpoint is designed to return standard identity claims to an OAuth client, and it shares Gitea's bearer-token authentication middleware. The defect (CWE-200, Exposure of Sensitive Information) is that userinfo authenticates the PAT but never checks whether the presented token carries a user/organization scope before assembling the email and groups claims, so a token that is functionally unprivileged for identity data at the REST layer is treated as fully privileged at the OIDC layer. Affected package is pkg:go/code.gitea.io/gitea at versions < 1.27.0.
RemediationAI
Vendor-released patch: upgrade to Gitea 1.27.0 or later, which enforces API token scopes on the OIDC userinfo endpoint (advisory GHSA-mg4f-x9v4-6h2p; release https://github.com/go-gitea/gitea/releases/tag/v1.27.0). If you cannot upgrade immediately, reduce exposure by treating existing personal access tokens as capable of reading identity/group data regardless of their assigned scope: revoke and reissue tokens granted to untrusted or third-party integrations, and avoid depending on narrow PAT scoping to hide org/team membership until patched. Where feasible, restrict network reachability of the /login/oauth/userinfo endpoint to trusted OIDC clients via a reverse proxy allowlist - note this side effect breaks legitimate OIDC relying parties that call userinfo, so apply it only if you are not using Gitea as an OIDC provider. Because the disclosure is limited to the token holder's own identity, the upgrade is the clean fix and workarounds are secondary.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4. Rated high severity (CVSS 7.1), this vulnerab
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-58138
GHSA-mg4f-x9v4-6h2p