CVE-2026-105267 in Gitea
Summary
by MITRE • 10/07/2026
The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag. A collaborator with Code write access and without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Gitea represents a critical authorization bypass within its web interface, specifically targeting the endpoint responsible for deleting tags via the POST method at the path /{owner}/{repo}/tags/delete. This flaw stems from an insufficient separation of duties and inadequate input validation within the application's backend logic. The core technical issue arises because the handler function for tag deletion is shared with the functionality for releasing deletions, yet it fails to perform a necessary verification step: confirming that the target entity being acted upon is strictly a plain git tag rather than a release object. In Gitea’s architecture, releases are distinct entities that can contain attachments and metadata, whereas tags are simple references to commits. By not distinguishing between these two types of objects before executing the deletion command, the system allows operations intended for one resource type to inadvertently affect another, leading to unintended data loss.
From an access control perspective, this vulnerability exploits a misalignment in permission scopes. The endpoint requires only write access to the Code unit, which is typically granted to collaborators who need to push changes or manage repository structure but do not necessarily have administrative privileges over releases. However, because the handler does not verify that the target is a plain tag, an authenticated user with Code write permissions can trigger the deletion logic for any identifier passed in the request payload. If this identifier corresponds to a release rather than a tag, the system proceeds to delete it. This creates a scenario where users who are explicitly denied Write access to Releases—perhaps due to organizational policies restricting release management to senior maintainers or CI/CD pipelines—are nonetheless able to permanently remove published releases and their associated attachments by exploiting the shared handler logic under the guise of deleting a tag.
The operational impact of this flaw is severe, primarily concerning data integrity and availability. Published releases often serve as stable points for software distribution, containing binaries, documentation, and other critical assets attached to them. The unauthorized deletion of these releases results in immediate and permanent loss of these artifacts unless backups are available. This can disrupt downstream processes such as automated deployments, package management systems, or user downloads that rely on the existence of specific release versions. Furthermore, because the action is performed by an authenticated user with legitimate Code write access, it may not trigger standard security alerts for external intrusions, making detection more difficult without rigorous audit logging and monitoring of repository events. The presence of protected tag rules provides a partial mitigation layer; if a release’s underlying git reference is covered by protection rules that prevent deletion or force-pushing, the attack vector is blocked at the Git level. However, this defense relies on correct configuration management and does not address the fundamental flaw in the application-layer authorization logic itself.
This vulnerability aligns with CWE-269, Improper Privilege Management, as it involves a user exercising permissions beyond their intended scope due to flawed access control checks. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, specifically within the context of Local Account Abuse or Remote Service Access, where an attacker leverages legitimate credentials and privileges to perform unauthorized actions against critical resources. To mitigate this issue, developers must enforce strict input validation that distinguishes between tag objects and release objects before executing deletion operations. The authorization logic should explicitly check for Release write permissions when the target is identified as a release, regardless of whether the request originates from an endpoint nominally designated for tags. Additionally, implementing comprehensive audit logging for all delete actions on releases can aid in forensic analysis and rapid incident response if such bypasses occur despite preventive controls.