Gitea CVE-2026-26231

Requires (1) network access to the Gitea web and Git HTTP/SSH endpoints, (2) any authenticated low-privilege account on the instance (read access to the target repository is sufficient - no write, fork-approval, or admin rights are needed), and (3) the instance must have SupportProcReceive enabled (the default on modern Gitea, used to power agit workflows), since the relaxed access-mode check in routers/web/repo/githttp.go and routers/private/serv.go is what defers enforcement to the vulnerable pre-receive hook. The target repository must be one the attacker can read and fork; entirely private repos they cannot view are not exposed. No user interaction by a victim is required, and the attack works against the repository's default branch.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N (8.5) accurately reflects a network-reachable, low-complexity flaw that needs only any low-privilege account, no user interaction, with a scope change (compromise of repositories the attacker does not own) and high integrity impact. Real-world risk is high for any multi-tenant Gitea instance that permits user registration or hosts public repositories - a single throwaway account is sufficient to backdoor every readable repo on the instance, which makes this a supply-chain-grade threat for code hosting. Publicly available exploit code exists in the form of poc.py linked from the GHSA advisory, raising practical exploitability further. No EPSS score or CISA KEV listing was provided in the input, so widespread or targeted exploitation cannot be confirmed at this time; analysts should treat exposure of pre-1.26.2 instances as urgent regardless. CVSS C:L is conservative - confidentiality impact is effectively limited to what was already readable, which is consistent with the bypass being write-side only.

An attacker registers (or uses any existing low-privilege account) on a target Gitea instance, forks a high-value public repository, then opens a PR with BASE set to their own fork and HEAD set to the upstream repository, ticking 'Allow edits from maintainers'. They clone their fork, craft a malicious commit (for example, backdooring a build script or CI workflow), and run git push against the upstream URL - the push is accepted and lands on the upstream default branch. A working poc.py is attached to the advisory and demonstrates the full chain end-to-end, dropping a PWNED.txt file on the victim repo's default branch.