Gitea CVE-2026-97208

Requires the caller to already hold repository-administrator privileges (CVSS PR:H) on a target repo. Critically, the flaw only crosses a security boundary on Gitea instances where the site administrator has explicitly enabled the [mirror] DISABLE_NEW_PUSH setting to forbid creation of new push mirrors via the web UI; on default configurations push mirrors are permitted, so the API behavior is not a violation. Exploitation is further limited to Gitea versions ≤28.0.0 (fixed in 28.1.0) and to instances with mirroring enabled. There is no unauthenticated or low-privilege path and no reliance on victim user interaction.

This is a genuinely low-priority issue despite the signals being internally consistent. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N, base 4.9 Medium) requires PR:H - a repository administrator - so the attacker is already a highly privileged, authenticated user, not an anonymous remote actor. All corroborating signals point the same way: EPSS is 0.16% (5th percentile), there is no CISA KEV listing, and the SSVC decision framework reports Exploitation=none, Automatable=no, and Technical Impact=partial. CWE-863 (improper authorization) accurately captures this as a policy-control bypass rather than a classic exploit. One notable discrepancy to verify: the input vector asserts I:H with C:N, yet the described behavior - pushing all repository refs to an attacker-chosen external remote - is fundamentally a data-exfiltration (confidentiality) problem, and the [mirror] DISABLE_NEW_PUSH control exists precisely to stop repo contents leaving the instance; the I:H/C:N labeling should be verified with the vendor advisory (GHSA-8hhh-mqpg-jpxc). Crucially, the bug only constitutes a security boundary crossing on instances where the site administrator deliberately enabled DISABLE_NEW_PUSH; on default configurations push mirrors are already permitted, so there is no violated control. Net assessment: low real-world risk, appropriate to patch on a normal cadence.

On a Gitea instance where the site administrator has set [mirror] DISABLE_NEW_PUSH to forbid new push mirrors, a user holding repository-administrator rights on any repo sends a crafted POST to /api/v1/repos/{owner}/{repo}/push_mirrors, which skips the setting check that the web UI enforces. The newly created push mirror then pushes all repository refs to a remote the attacker controls, exfiltrating repository contents on each commit or on schedule. No public exploit identified at time of analysis, though the fix PR (go-gitea/gitea#39501) documents the exact code path.