CVE-2026-129337 in Gitea
Summary
by MITRE • 11/15/2026
Git over HTTP lowers the required permission for pushes to read access, so that the AGit flow works, and relies on the repository's server-side hooks to enforce write access. A repository that is still being created by a migration, fork or template generation has no hooks yet, so a user with read access to it could push branches and tags during that window, or after a failed migration that left the repository in that state. Git over HTTP now refuses requests to repositories that are still being created.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability described involves a logic flaw within the Git over HTTP protocol implementation regarding permission enforcement for write operations such as pushing branches and tags. Historically, systems utilizing this flow lowered the required client-side permissions from write access down to read access to facilitate specific workflows like automated migrations or template generation. This architectural decision relied entirely on server-side hooks to validate whether a user had legitimate authority to perform the push operation. While this approach streamlined certain administrative tasks by reducing initial permission requirements, it introduced a critical race condition and state-dependent security gap where the integrity of write operations was contingent upon the presence and execution of specific server-side scripts rather than immediate access control checks at the protocol level.
The core technical flaw emerges during transient states in repository lifecycle management, specifically when a repository is being created via migration, fork, or template generation processes. During these initialization phases, the necessary server-side hooks that enforce write permissions have not yet been instantiated or configured on the target repository. Consequently, any user possessing read access to the repository can successfully push branches and tags because the HTTP endpoint accepts the request without verifying actual write privileges, assuming the hook will later reject invalid operations if they occur after initialization. This creates a window of opportunity where unauthorized modifications can be committed before the security controls are fully active. Furthermore, this risk persists in scenarios involving failed migrations or incomplete setup processes that leave repositories in an intermediate state lacking these protective hooks, effectively bypassing intended access restrictions for any user with read-level privileges.
The operational impact of this vulnerability allows attackers or malicious insiders to modify repository content during these vulnerable windows. By pushing unauthorized branches or tags, they can introduce code changes, alter version history, or potentially inject malicious artifacts into the project before proper validation occurs. This undermines the principle of least privilege and compromises the integrity of the software supply chain within the affected platform. The reliance on asynchronous hook execution rather than synchronous access control checks creates a significant security gap where state management failures directly translate to unauthorized write capabilities.
To mitigate this risk, the system has been updated to refuse Git over HTTP requests for repositories that are still in the creation phase or otherwise lack proper initialization status. This change enforces stricter permission validation at the point of request receipt rather than deferring it to post-commit hooks. By rejecting operations on uninitialized repositories, the platform ensures that only fully configured and secured repositories accept write traffic from users with appropriate permissions. Administrators should verify that their systems are updated to this newer version which implements these synchronous checks. Additionally, reviewing existing repository configurations for any lingering states resulting from previous failed migrations is recommended to ensure no legacy instances remain vulnerable to similar exploitation vectors before the patch takes full effect across all environments.