CVE-2026-119441 in Gitea
Summary
by MITRE • 11/01/2026
`DELETE /api/v1/orgs/{org}/repos` deletes all repositories of an organization, but it did not enforce the public-only restriction of access tokens: the route only checked that the organization itself was public. A public-only token of an owner of a public organization could therefore permanently delete the organization's private repositories, which such a token must not reach. Routes that require organization ownership now reject public-only tokens.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/01/2026
This vulnerability represents a critical authorization bypass within the API endpoint responsible for deleting all repositories associated with a specific organization. The core technical flaw lies in an incomplete access control check during the execution of the DELETE request to /api/v1/orgs/{org}/repos. While the system correctly verified that the target organization was public, it failed to validate whether the authentication token presented by the user possessed sufficient privileges for private resource manipulation. Specifically, the logic relied solely on the visibility status of the organization rather than enforcing a strict separation between public and private data scopes based on the token type. This oversight allowed an attacker possessing only a public-only access token, which is designed to restrict operations to publicly visible resources, to execute destructive actions against private repositories owned by that organization if they held ownership rights within it.
The operational impact of this flaw is severe, as it enables unauthorized permanent data destruction. An actor with a limited-privilege token could inadvertently or maliciously delete all codebases, issues, and associated metadata for an entire organization's private projects. This results in significant availability loss and potential intellectual property exposure if backups are not readily available. The breach of confidentiality is secondary to the integrity violation here, as the primary consequence is the irreversible removal of critical development assets. Such actions can disrupt continuous integration pipelines, halt software delivery cycles, and cause substantial financial and reputational damage to the affected organization.
From a classification perspective, this issue aligns with CWE-269, which denotes Improper Privilege Management, specifically where an actor operates without necessary privileges for the action performed. It also relates to CWE-862, Missing Authorization, as the system failed to enforce access control policies that should have restricted private repository deletion based on token scope. In terms of adversary tactics, this vulnerability facilitates lateral movement and impact through resource destruction, mapping closely to ATT&CK technique T1485, Data Destruction, where an attacker deletes data or distorts it in a way that renders the information unusable for its intended purpose.
The remediation strategy involved tightening the authorization logic within routes that require organization ownership. The fix ensures that any operation demanding organizational administrative privileges now explicitly rejects public-only tokens. This enforces a principle of least privilege by ensuring that high-impact actions are restricted to tokens with elevated permissions, thereby preventing users from leveraging limited-access credentials to perform destructive operations on private resources. Future development processes should incorporate automated testing for authorization boundaries across all API endpoints to detect similar discrepancies between resource visibility and token scope requirements before deployment.