CVE-2026-70396 in Gitea
Summary
by MITRE • 10/14/2026
Gitea's organization repository-creation API requires write:organization but omits the write:repository token scope enforced by other repository-creation routes. A personal access token or OAuth application token without repository-write scope can therefore create organization-owned repositories if the authorizing user has permission to do so. This bypasses the token's delegated scope boundary while remaining subject to the user's organization permissions.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability in Gitea represents a significant authorization flaw within its API layer, specifically affecting the mechanism for creating new repositories under an organization account. The core issue stems from an inconsistency in how access control scopes are enforced across different endpoints that perform similar functions. While standard repository creation routes correctly mandate the write:repository token scope to ensure that only tokens with explicit permission to manage code can create such assets, the organization-specific repository-creation API endpoint erroneously relies solely on the write:organization scope. This discrepancy allows a user possessing a personal access token or OAuth application token limited strictly to organizational management tasks to bypass the intended restriction against creating new repositories.
From a technical perspective, this flaw constitutes an Authorization Bypass through User-Controlled Key issue, aligning with CWE-284 in the Common Weakness Enumeration taxonomy. The vulnerability exploits the fact that Gitea checks for high-level administrative privileges within an organization without verifying whether the specific action requires granular permissions related to repository management. Consequently, a token scoped only to write:organization is treated as sufficient authority to execute operations that fundamentally alter the codebase structure by adding new repositories. This bypasses the principle of least privilege, which dictates that users and applications should be granted only the minimum levels of access necessary to perform their intended functions.
The operational impact of this vulnerability allows attackers or malicious insiders with limited token scopes to expand an organization's footprint beyond authorized boundaries. An attacker could create unauthorized repositories within a target organization, potentially using them as staging grounds for malware distribution, phishing campaigns, or further exploitation attempts against other members of that organization. Since the action remains subject to the user's existing organizational permissions, it does not require escalating privileges from read-only access but rather exploits the over-permissive nature of the write:organization scope when applied to repository creation tasks. This can lead to data leakage if sensitive code is inadvertently committed to these newly created repositories or if they are used to compromise downstream CI/CD pipelines that trust organization-owned assets.
This behavior also maps directly to MITRE ATT&CK technique T1098, specifically the aspect of Account Manipulation where an actor adds credentials to a cloud account to maintain persistent access. In this context, while not adding new user accounts, the attacker is manipulating the organizational structure by injecting unauthorized entities (repositories) that can be leveraged for subsequent malicious activities. The lack of scope validation means that automated tools or scripts running with limited permissions could inadvertently trigger repository creation if configured incorrectly, leading to cluttered environments and potential security misconfigurations in newly created projects.
To mitigate this vulnerability, Gitea administrators should ensure they are running a patched version where the API endpoint has been corrected to enforce the write:repository scope alongside any organizational checks. In the interim, organizations can implement stricter token policies by auditing existing personal access tokens and OAuth applications for those holding write:organization scopes without corresponding repository management needs. It is advisable to revoke or restrict such broad-scoped tokens if they are not strictly required for administrative tasks that genuinely necessitate organization-wide control. Additionally, enabling detailed audit logging on the Gitea instance can help identify any unauthorized attempts to create repositories using improperly scoped tokens, allowing security teams to detect and respond to potential exploitation activities promptly.