Gitea CVE-2026-105267

Requires an authenticated repository collaborator who holds write access to the Code unit but does not have Releases write access (the exact privilege-boundary this bug crosses); exploitation is a single POST to /{owner}/{repo}/tags/delete against the release's tag on an unpatched instance (Gitea ≤28.0.0). Key limiting factors: the attacker must already be a trusted collaborator with Code write on the target repository (not an anonymous outsider), and releases whose tags are covered by Protected Tag rules remain safe - those rules still blocked the deletion, so protected-tag configuration meaningfully mitigates real-world impact.

This is a broken-access-control / improper authorization flaw (CWE-732) in Gitea's tag-deletion web route, which shared a handler with release deletion and failed to verify the target was a plain tag. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, base 8.1) indicates network-reachable, low-complexity exploitation by a low-privileged authenticated user, with high integrity and availability impact and no confidentiality impact. The real-world signals argue against treating this as a top-tier emergency: EPSS is only 0.17% (6th percentile), it is NOT on CISA KEV, no public exploit code is referenced (the only 'source code evidence' is the vendor fix PR, not a weaponized POC), and SSVC scores Exploitation=none, Automatable=no, Technical Impact=partial. These signals are internally consistent - a high-CVSS integrity/availability issue that is nonetheless not actively exploited and not trivially automatable at scale, because it requires an attacker to already be a trusted collaborator with Code write access on the specific repository. Note one conflict worth flagging: the input Tags label this 'Information Disclosure', but the CVSS vector sets C:N and the impact is data destruction (releases and attachments), so the disclosure framing is incorrect - this is an integrity/availability issue. Net: a legitimate insider-privilege-escalation bug that platform operators with multi-collaborator repositories should patch, but not a mass-exploitation 'drop everything' priority.

A repository collaborator who has been granted write access to the Code unit but deliberately NOT given Releases write access sends a crafted POST to /{owner}/{repo}/tags/delete targeting the tag of a published release. Because the shared handler did not confirm the target was a plain tag, the release and all of its attachments are permanently deleted, bypassing the intended Releases-permission boundary. No public exploit code is identified at time of analysis; the request is simple enough to issue manually against any unpatched instance where the attacker holds Code write.