Gitea EUVD-2026-41636

Exploitation requires the attacker to already hold a legitimate per-branch write/maintainer-edit grant on at least one ref of the target Gitea repository (for example, 'allow maintainer edits' enabled on their pull request branch), and requires pushing multiple refs within a single pre-receive hook session so the cached permission is reused. It is limited to Gitea 1.25.5 (fixed in 1.26.3): an attacker with zero prior access to the repository cannot trigger it, so instances that grant no per-branch write to untrusted users, or that have upgraded, are not exploitable. No user interaction from a victim is needed (UI:N), and access is network-reachable (AV:N) via normal Git-over-HTTP/SSH push.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:H, base 8.8) reflects an easy, network-reachable, low-privilege escalation with no user interaction - realistic for any Gitea instance with untrusted or semi-trusted collaborators. However, the low-privilege prerequisite is meaningful: an attacker must already possess a legitimate per-branch maintainer-edit grant (e.g., via an accepted pull request with 'allow maintainer edits'), so this is an insider/collaborator escalation, not a fully anonymous compromise. Signals are internally consistent but point to bounded real-world urgency: EPSS is only 0.20% (10th percentile), there is no CISA KEV listing and no public exploit identified, indicating no evidence of active or widespread exploitation. No SSVC decision record is provided in the input. Net: a genuine, high-severity authorization bug worth prompt patching on multi-tenant or public-facing Gitea instances, but not an emergency drop-everything item for tightly controlled single-tenant deployments. Note the C:H/A:H components are somewhat generous - the primary demonstrated impact is integrity (write access); verify confidentiality/availability relevance against your branch-protection model.

A semi-trusted collaborator opens a pull request and is granted per-branch maintainer-edit rights on a single feature branch. In one Git push (a single pre-receive hook session) they include updates to additional refs - such as a protected main branch or release tag - and Gitea reuses the cached branch-level approval to authorize all of them, giving the attacker full repository write. No public exploit code has been identified, but the low complexity (AC:L) makes the technique straightforward to reproduce once the caching behavior is understood.