CVE-2026-125617 in Gitea
Summary
by MITRE • 11/15/2026
`GET /api/v1/users/{username}/orgs/{org}/permissions` only checked that the organization is visible to the caller and then returned the named user's role in it. Any signed-in user could learn whether another user is an owner, admin or member of a public or limited organization, including for members who conceal their membership. The roles are now only returned to the user themselves, to members of the organization and to site administrators.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified in this CVE represents a critical authorization flaw within the application's API endpoint responsible for retrieving organizational permissions. Specifically, the GET /api/v1/users/{username}/orgs/{org}/permissions endpoint failed to enforce proper access control checks regarding who is permitted to view role assignments. The original implementation logic relied solely on verifying that the target organization was visible to the authenticated caller. This check was insufficient because visibility of an organization does not equate to authorization to inspect its internal membership roles, particularly for users whose participation in limited or private organizations they wish to keep confidential. Consequently, any signed-in user could query this endpoint with arbitrary usernames and organization identifiers to determine if a specific individual holds the role of owner, administrator, or member within that entity.
This flaw leads directly to an unauthorized information disclosure scenario where sensitive membership data is exposed beyond its intended scope. The operational impact includes the ability for malicious actors to map out organizational structures, identify high-privilege accounts such as owners and admins, and potentially target these individuals with social engineering attacks or privilege escalation attempts. Furthermore, this vulnerability undermines privacy expectations by revealing memberships that users have explicitly attempted to conceal from other community members. By exposing whether a user is part of a public or limited organization regardless of their visibility settings, the application fails to protect sensitive personal data associated with professional affiliations and group associations.
From a technical perspective, this issue aligns with CWE-284 Improper Access Control, as the system did not properly restrict access to resources based on user identity and privileges. It also relates closely to CWE-601 URL Redirection to Untrusted Site in terms of logic flow errors where input validation is incomplete, though more accurately it fits CWE-862 Missing Authorization since the application failed to enforce that a user must be an authorized member or administrator before accessing role data. In the context of the MITRE ATT&CK framework, this vulnerability facilitates reconnaissance activities by allowing attackers to gather information about victim organizational structures and key personnel, which is categorized under T1592 Gather Victim Host Information or more specifically T1087 Account Discovery when used to enumerate administrative accounts within a target organization.
To mitigate this risk, the application logic has been updated to strictly limit role visibility. The endpoint now returns user roles exclusively to three specific groups: the user themselves, other verified members of that particular organization, and site-level administrators with global oversight privileges. This change ensures that membership data is not exposed to external parties or unauthorized internal users who lack a legitimate business need for such information. Implementing robust object-level access control checks that verify the requester's relationship to both the resource (the user) and the context (the organization) before returning sensitive attributes is essential. Additionally, organizations should conduct regular security audits of their API endpoints to ensure that visibility settings do not inadvertently leak privileged role data through related or nested API calls.