CVE-2026-118395 in Gitea
Summary
by MITRE • 11/01/2026
Gitea 1.27.3 stopped personal access tokens restricted to public resources (`public-only`) from creating repositories through `POST /api/v1/user/repos` and `POST /api/v1/repos/migrate`, but `POST /api/v1/org/{org}/repos`, `POST /api/v1/orgs/{org}/repos`, `POST /api/v1/orgs` and `POST /api/v1/repos/{owner}/{repo}/generate` still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates. The token still could not read the private repositories it created.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability identified in Gitea versions prior to 1.27.4 represents a significant authorization bypass within the application’s API layer, specifically affecting tokens designated with public-only restrictions. In standard security operations, personal access tokens are often scoped to limit their capabilities based on sensitivity; for instance, a token restricted to public resources should theoretically be unable to interact with private data or create entities that result in private storage. The core technical flaw lies in an inconsistency within the middleware and handler logic responsible for validating token scopes against specific API endpoints. While recent patches correctly enforced these restrictions on user-level repository creation via POST /api/v1/user/repos and migration operations, they failed to apply the same rigorous checks to organization-centric endpoints such as POST /api/v1/org/{org}/repos, POST /api/v1/orgs/{org}/repos, POST /api/v1/orgs, and the template generation endpoint at POST /api/v1/repos/{owner}/{repo}/generate. This oversight allowed an attacker possessing a public-only token with appropriate write scopes to bypass intended limitations by targeting these specific organizational APIs rather than user-level ones.
The operational impact of this vulnerability is substantial because it enables privilege escalation from a restricted, low-privilege context to one capable of creating private assets within the organization structure. An authenticated actor holding such a compromised or misconfigured token can create new repositories that are set to private visibility, even though their token explicitly forbids interaction with public resources only if those interactions were properly validated across all entry points. Furthermore, the attacker is not limited to repository creation; they can also generate entire organizations and produce private repositories from existing templates using these unchecked endpoints. This capability effectively allows an external or low-privileged user to establish persistent footholds within the organization’s namespace under the guise of legitimate administrative actions, potentially leading to data exfiltration if other vulnerabilities exist that allow reading content created by such tokens, although the report notes a specific limitation where the token itself cannot directly read the private repositories it creates.
From an industry standard perspective, this flaw is classified as CWE-269: Improper Privilege Management, specifically illustrating a failure to enforce role-based access control (RBAC) consistently across all application functions. The attack vector aligns with MITRE ATT&CK technique T1078: Valid Accounts, where the adversary leverages legitimate credentials that have been improperly scoped or exploited due to logical errors in permission checks. It also touches upon CWE-926: Improper Export of Information with Restricted Access if one considers the creation of private structures as a form of unauthorized state change leading to potential information exposure through subsequent exploitation chains. The inconsistency between user-level and organization-level API handlers highlights a common architectural weakness where security controls are implemented in isolated modules rather than being enforced by a centralized, unified authorization service that applies policies uniformly regardless of the endpoint targeted.
Mitigation for this vulnerability requires an immediate upgrade to Gitea version 1.27.4 or later, which addresses these specific API endpoints and ensures that public-only tokens are correctly rejected when attempting to create private repositories, organizations, or generate private content from templates. In environments where upgrading is not immediately feasible, administrators should implement strict network-level controls such as Web Application Firewalls (WAF) rules that monitor for anomalous patterns of repository creation via organization APIs by accounts with restricted token scopes. Additionally, auditing logs for frequent POST requests to /api/v1/orgs or similar endpoints from users who do not typically perform administrative actions can help detect exploitation attempts in real-time. Long-term remediation should involve a comprehensive review of the application’s authorization middleware to ensure that scope validation is decoupled from specific endpoint implementations and instead applied as a global policy check before any business logic executes, thereby preventing future inconsistencies where certain paths bypass security constraints while others do not.