CVE-2026-118394 in Gitea
Summary
by MITRE • 11/01/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability identified in this report stems from a fundamental flaw in how the OAuth2 userinfo endpoint processes authentication credentials, specifically regarding the determination of data visibility for the groups claim. In secure identity and access management systems, it is critical that the permissions granted by an access token strictly dictate what information can be retrieved about the authenticated user. The affected implementation incorrectly re-parsed the Authorization header to interpret the credential as a standard OAuth2 access token rather than relying on the scope associated with the original authentication context. This architectural misstep created a discrepancy between the intended security boundaries and the actual data exposure, allowing for an unauthorized information disclosure scenario where sensitive organizational metadata was accessible under conditions that should have restricted it.
The technical root cause lies in the endpoint's logic for validating access rights to private resources such as organizations, teams, and concealed memberships. When a request is made with a token scoped only to public entities, or when a personal access token with limited visibility is used, the system was designed to return an empty groups claim to respect those restrictions. However, due to the flawed re-parsing mechanism, the endpoint failed to correctly apply these scope limitations in certain transmission methods. Specifically, if the OAuth2 access token was transmitted via query parameters or form fields rather than strictly through standard headers, or when specific types of personal access tokens were utilized, the validation logic bypassed the intended public-only constraints. Consequently, the system erroneously populated the groups claim with data belonging to private organizations and concealed memberships that the user should not have been able to view based on their token's scope.
The operational impact of this vulnerability is primarily informational but carries significant privacy implications for enterprise users. The disclosure is limited strictly to organizational identifiers, including organization names, team names, and membership statuses such as whether a user belongs to a concealed group or private team. No actual repository content, code, secrets, or sensitive business data within those repositories was exposed during this flaw. Nevertheless, the exposure of internal structure allows an attacker with access to public-facing APIs or endpoints to map out an organization's hierarchy, identify key teams, and understand membership distributions without proper authorization. This type of reconnaissance can facilitate further social engineering attacks or aid in planning more targeted exploits against specific individuals within those private groups by revealing their affiliations and roles.
To mitigate this risk, the endpoint has been updated to correctly utilize the scope of the authenticating token for all access decisions regarding the groups claim. This ensures that data visibility is consistently enforced based on the permissions granted at the time of authentication, regardless of how the token is transmitted or which specific type of credential is used. Organizations relying on this API should verify that their integration patterns adhere to standard OAuth2 best practices, such as transmitting tokens via the Authorization header rather than query parameters where possible, although the fix addresses both vectors. Security teams should also audit any custom scripts or applications that consume this userinfo endpoint to ensure they are not inadvertently exposing internal organizational structures in logs or responses, and consider implementing additional monitoring for unusual access patterns related to group membership queries until all systems have been patched.
This incident aligns with CWE-200, which classifies the exposure of information to an unauthorized actor as a significant security weakness, particularly when that information aids in further attacks against the system's integrity or confidentiality. From a tactical perspective, this vulnerability reflects techniques associated with ATT&CK ID T1539, specifically Steal Web Session Cookie, although adapted here for token-based authentication contexts where session tokens are extracted via API endpoints rather than browser cookies. The failure to correctly enforce scope boundaries represents a classic access control flaw that underscores the importance of rigorous validation logic in identity providers and APIs handling sensitive user metadata.