CVE-2026-116296 in Gitea
Summary
by MITRE • 11/01/2026
The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping their download URLs, delete releases and tags, and create, edit or delete milestones and labels of a repository that is meant to be read-only. Changing requests on these routes now return 423 Locked for archived repositories.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/01/2026
The identified vulnerability represents a critical authorization bypass within the API endpoints governing software release management artifacts, specifically affecting releases, release assets, milestones, and repository labels. In standard version control workflows, archiving a repository is intended to enforce a read-only state, preventing any modifications that could alter historical records or disrupt established deployment pipelines. However, the affected system failed to validate the archival status of repositories when processing write operations through these specific API routes. This oversight allowed users possessing write access permissions, as well as holders of valid authentication tokens scoped with those same privileges, to execute destructive and modifying actions on repositories that were explicitly designated as archived. The core technical flaw lies in the absence of a pre-condition check for repository archival status within the request handling logic for these endpoints, effectively treating archived repositories identically to active ones regarding write permissions.
The operational impact of this vulnerability is severe, particularly for organizations relying on immutable release artifacts for compliance and security auditing. An attacker or malicious insider with compromised credentials could replace existing release assets while preserving their original download URLs. This technique allows the distribution of tampered binaries without alerting users who rely on stable links to verify integrity via checksums before downloading. Furthermore, the ability to delete releases and tags disrupts version history traceability, making it difficult for development teams to audit changes or roll back to known good states. The capability to create, edit, or delete milestones and labels further degrades project management integrity, potentially leading to confusion regarding release timelines and feature tracking. This behavior directly contradicts the fundamental security principle that archived data should be protected from modification to maintain historical accuracy and system stability.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as it involves an elevation of privileges or bypassing intended restrictions through insufficient access control checks on specific API endpoints. It also relates closely to CWE-732 Incorrect Permission Assignment for Critical Resource, where the resource (the archived repository) is not assigned the correct restrictive permissions required by its state. In terms of adversary tactics, this behavior facilitates techniques associated with MITRE ATT&CK T1498 Network Denial of Service, specifically through asset deletion or corruption, and potentially supports supply chain attacks if malicious assets are injected into trusted release channels. The persistence of download URLs during asset replacement is particularly dangerous as it enables a form of silent compromise where the distribution mechanism remains unchanged while the content becomes hostile.
To mitigate this vulnerability, immediate updates to the API gateway logic must be implemented to enforce strict validation checks that reject any write operations on repositories marked with an archived status. The system should return a 423 Locked HTTP response code for all such attempts, clearly signaling to clients and administrators that the resource is immutable due to its archival state. Administrators should review access logs for anomalies indicating exploitation of these endpoints prior to patching, looking for unusual patterns in release asset modifications or deletions on archived projects. Additionally, organizations should enforce strict token scoping policies, ensuring that write permissions are not granted unnecessarily and that automated systems interacting with APIs respect the immutable nature of archived repositories. Regular audits of API endpoint configurations against security baselines can help prevent similar logic flaws from being introduced during future development cycles.