CVE-2026-117635 in Gitea
Summary
by MITRE • 11/01/2026
The `/api/v1/admin` route group did not enforce the `public-only` restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could therefore list private organizations and the email addresses of all users, create organizations, obtain runner registration tokens and create new site administrator accounts, the last of which persists after the token is revoked. Tokens of users who are not site administrators cannot reach these routes; public-only tokens are now rejected on the admin API.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability identified in the GitLab administrative API endpoint represents a critical authorization bypass within the access control logic governing personal access tokens. Specifically, the `/api/v1/admin` route group failed to correctly enforce the `public-only` restriction associated with certain token scopes. In standard security models for identity and access management systems like OAuth 2.0 or similar proprietary implementations used by GitLab, tokens are often categorized by their visibility and privilege levels. A public-only token is designed to expose only non-sensitive data that does not compromise user privacy or system integrity. However, due to the implementation flaw, a malicious actor possessing such a token with an admin scope was able to bypass these restrictions entirely. This misconfiguration allowed the attacker to treat a restricted token as if it possessed full administrative privileges without the necessary authentication constraints intended for higher-security tokens.
The operational impact of this vulnerability is severe, encompassing both data exfiltration and complete system compromise. An attacker leveraging an affected public-only admin token could enumerate private organizations within the instance, effectively violating the confidentiality boundaries established by organization owners. Furthermore, the flaw permitted the extraction of email addresses from all users on the platform, facilitating large-scale phishing campaigns or credential stuffing attacks against individual accounts. Beyond data theft, the vulnerability allowed for active system manipulation. The attacker was able to create new private organizations and obtain runner registration tokens, which could be used to execute arbitrary code within the CI/CD pipeline infrastructure under the context of those runners. Most critically, the flaw enabled the creation of new site administrator accounts. This action grants persistent administrative control over the entire instance, allowing for further exploitation even after the initial compromised token is revoked or deleted by its owner.
This incident highlights a significant failure in the principle of least privilege and proper scope validation within the API gateway layer. The persistence of created admin accounts post-revocation indicates that the vulnerability also involved flaws in session management or account lifecycle handling, allowing attackers to maintain long-term access despite remediation efforts on the token side. Such behavior aligns with CWE-269 (Improper Privilege Management) and CWE-862 (Missing Authorization), as the system failed to verify whether the specific type of token presented was authorized for administrative actions. From an ATT&CK perspective, this maps directly to T1078 (Valid Accounts) via misuse of legitimate credentials with elevated privileges, and potentially T1136 (Create Account) through the unauthorized creation of admin users. The ability to register runners also touches upon supply chain attack vectors where compromised infrastructure can be used for cryptomining or data exfiltration from within the network perimeter.
To mitigate this vulnerability, immediate steps must include revoking all existing public-only tokens that possess administrative scopes and enforcing strict validation logic at the API routing level to reject any attempt by non-admin users or restricted token types to access admin endpoints. The system architecture should be reviewed to ensure that scope checks are performed before route execution rather than relying solely on user role verification, which can sometimes be bypassed if token metadata is not correctly parsed. Additionally, organizations must audit existing administrator accounts for unauthorized entries and implement multi-factor authentication for all administrative actions to reduce the risk of persistent access via created admin accounts. Long-term remediation involves implementing a comprehensive identity governance framework that regularly audits token permissions and enforces strict separation between public-facing API endpoints and internal administrative interfaces.