CVE-2026-73814 in Gitea
Summary
by MITRE • 10/14/2026
Gitea's collaboration access-mode endpoint accepts the Owner access mode from an authenticated repository collaborator with Admin access. The collaborator can promote their effective permissions from Admin to Owner and then perform owner-only operations, including transferring the repository to their own account. This bypasses the intended boundary between repository administration and ownership.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Gitea represents a critical privilege escalation flaw within the collaboration access control mechanisms of the platform. Specifically, the endpoint responsible for managing collaboration modes fails to enforce strict validation on the target permission level when modified by an authenticated user with Admin privileges. While standard security models dictate that repository administrators should have full operational control over code and settings without assuming ultimate ownership rights, this implementation allows a collaborator holding Admin access to explicitly request or set their own role to Owner through the API interface. This logical error effectively bypasses the intended boundary between administrative duties and proprietary ownership, allowing users who are not the original creators of the repository to elevate their status beyond what is logically permissible for an administrator.
From a technical perspective, this flaw stems from insufficient authorization checks on the server side when processing requests that modify user roles within a repository context. The system accepts the Owner access mode parameter without verifying whether the requesting user currently holds sufficient privileges or if such a transition violates organizational policies regarding ownership transfer. In secure software design, role transitions typically require either explicit approval from the current owner or strict validation of preconditions to prevent unauthorized elevation of privilege. By failing to validate these constraints, Gitea allows an authenticated Admin collaborator to self-promote, thereby gaining complete control over the repository including the ability to delete it, change its visibility settings, and most critically, transfer ownership to another account under their sole control.
The operational impact of this vulnerability is severe for organizations relying on Gitea for source code management and collaborative development. An attacker who gains access to an account with Admin privileges on a target repository can exploit this flaw to seize full ownership rights. Once the user promotes themselves to Owner, they gain unrestricted ability to transfer the repository to their own personal or external account. This action effectively results in data theft and loss of control for the original organization. The compromised codebase may contain sensitive intellectual property, proprietary algorithms, or confidential project details that are now under the sole discretion of the attacker. Furthermore, because this is an API-based vulnerability, it can be exploited programmatically at scale, making it particularly dangerous against large organizations with numerous repositories where administrative access might have been granted broadly to facilitate collaboration.
This issue aligns closely with CWE-269, which describes Improper Privilege Management, as the system fails to maintain proper separation of duties and allows unauthorized elevation of privileges. Additionally, from a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability facilitates lateral movement within an organization's infrastructure by allowing an attacker to pivot control over critical assets (the repositories) after initial compromise or credential theft. It also supports techniques related to Account Manipulation and Data Exfiltration via Transfer of Ownership. To mitigate this risk, immediate updates to the Gitea instance are required as patches have been released that enforce stricter validation on role modification endpoints. Administrators should ensure all instances are updated to the latest stable version where these access control checks are hardened. In environments where patching is not immediately possible, restricting API permissions for collaborator roles and auditing repository ownership transfer logs can help detect or prevent exploitation attempts until a permanent fix is applied.