CVE-2026-97208 in Gitea
Summary
by MITRE • 10/07/2026
The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Gitea represents an authorization bypass within the REST API layer that allows unauthorized creation of push mirrors for repositories where such functionality has been explicitly disabled at the site level. This flaw stems from an inconsistency between the security controls enforced by the web interface and those applied to programmatic access via the application programming interface. Specifically, when a repository administrator attempts to create a new push mirror using the POST endpoint located at /api/v1/repos/{owner}/{repo}/push_mirrors, the system performs only a superficial check to determine if mirroring is generally enabled for that specific repository. It fails to validate the global configuration setting known as DISABLE_NEW_PUSH within the [mirror] section of the application's configuration file. This oversight creates a significant security gap because it allows an authenticated user with administrative privileges over a single repository to bypass site-wide restrictions intended by the system administrator.
From a technical perspective, this issue is classified under CWE-269, which denotes Improper Privilege Management, as well as CWE-862, Missing Authorization Check. The root cause lies in the application logic not propagating global configuration constraints into the API handler responsible for mirror creation. In secure software design, security policies defined at a higher level of hierarchy, such as site-wide settings, must be strictly enforced by all entry points, including both graphical user interfaces and programmatic APIs. By neglecting to check the DISABLE_NEW_PUSH flag during the API request processing, Gitea inadvertently grants capabilities to repository administrators that were explicitly revoked for them by the infrastructure team. This discrepancy highlights a common architectural weakness where security controls are implemented piecemeal rather than through centralized policy enforcement mechanisms.
The operational impact of this vulnerability is substantial, particularly in environments where push mirrors pose a risk due to data sensitivity or compliance requirements. A push mirror automatically pushes all references from the local repository to a remote destination chosen by the caller on every commit or according to a scheduled interval. If an attacker or malicious insider exploits this flaw, they can establish unauthorized synchronization channels that exfiltrate code changes to external servers controlled by third parties. This could lead to intellectual property theft, leakage of proprietary source code, or the introduction of compromised dependencies if the remote destination is manipulated. Furthermore, in regulated industries where audit trails and strict access controls are mandatory, this bypass undermines compliance efforts by allowing data transfer outside of approved channels without triggering standard administrative alerts associated with mirror creation through the web interface.
To mitigate this risk, immediate action should be taken to upgrade Gitea to a version that includes the patch for this authorization check inconsistency. Until an update is applied, administrators can implement compensating controls such as restricting API access at the network level using firewalls or reverse proxies, ensuring that only trusted IP addresses can reach the API endpoints. Additionally, auditing existing push mirrors and reviewing user permissions within repositories can help identify any unauthorized configurations already in place. Long-term remediation involves adopting a defense-in-depth strategy where all security checks are centralized and consistently applied across both web-based and API-driven interactions to prevent similar bypasses in other features of the platform. This incident underscores the importance of rigorous code review processes that verify configuration inheritance from global settings down to individual endpoint handlers, ensuring alignment with ATT&CK techniques related to unauthorized access and data exfiltration via legitimate system functions.