Gitea EUVD-2026-93918

Requires the attacker to possess a deploy key with write (read-write) access to the target repository; a plain read-only deploy key is insufficient. Exploitation occurs during an authenticated git push whose hook pipeline mis-records the repository owner as the pusher, so the attacker inherits the owner's authorization. Concrete abuse paths named in the advisory: creating protected tags while absent from the tag allow list, and changing repository visibility (e.g. private→public) via git push options; AGit-flow pull requests are also misattributed to the owner. Limiting factors: no exploitation without a writable deploy key (authenticated precondition, PR:L), no user interaction, and only Gitea instances at or below 1.27.3 are affected.

Signals are consistent and point to a genuine but moderate, access-gated risk rather than a widespread emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, 7.1 High) requires privileges (PR:L) - specifically possession of a writable deploy key - which materially limits the attacker population to those already granted repository write via a deploy key. This is corroborated by CISA SSVC (Exploitation: none, Automatable: no, Technical Impact: partial), which indicates no observed exploitation and that the flaw is not trivially scalable. EPSS is very low at 0.15% (3rd percentile), and the vulnerability is NOT in CISA KEV, so there is no public exploit identified at time of analysis. The C:H rating is driven by the ability to flip a private repository to public (information disclosure), while integrity is only Low (creating protected tags / changing push-option-controlled settings) and availability is unaffected. No signals conflict; all sources agree this is a real authorization-bypass bug (CWE-863) worth patching promptly for any instance that issues deploy keys, but it is not a mass-exploitation priority. One caveat: the CVSS labels this an unchanged scope (S:U) even though making a private repo public arguably crosses a trust boundary - defenders may consider the real-world confidentiality impact slightly higher than S:U suggests.

An attacker who holds (or compromises) a read-write deploy key for a Gitea repository performs a git push; because the push hook pipeline records the repository owner as the pusher, the attacker's push is evaluated with the owner's permissions. Using push options, they flip the private repository to public to exfiltrate its contents, or create protected tags despite not being on the tag allow list. No public exploit code is identified, but the fix PR (#37306) documents the exact code paths involved.