Gitea CVE-2026-89430

Requires: (1) an authenticated Gitea account, which inherently grants administrator rights over any repository the user creates, so no pre-existing elevated privilege is needed; (2) the push-mirror feature in use on a repository; (3) attacker control over DNS resolution of the configured remote hostname so it resolves to an allowed address when the mirror is created and later to a blocked/internal address at synchronization time (the CWE-367 time-of-check/time-of-use gap); and (4) an internal Git service that is network-reachable from the Gitea server. Limiting factors: exploitation only matters where the [migrations] allow/block lists are actually configured to protect internal ranges, the attacker must be able to influence DNS/name resolution, and value is realized only if reachable internal Git endpoints exist. No end-user interaction is required.

Signals are consistent and point to a real-but-bounded risk rather than a mass-exploitation emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable flaw requiring only low privileges - and the description clarifies that "administrator access to a repository" is trivially obtained because any user gets admin on repositories they create themselves, so this effectively reduces to any authenticated Gitea user. However, EPSS is very low (0.12%, 2nd percentile), there is no CISA KEV listing, and SSVC reports Exploitation: none and Automatable: no, all of which argue against widespread opportunistic attacks. The CWE-367 (TOCTOU) nature explains the low automatability: exploitation depends on the attacker controlling DNS resolution so a name validated as safe at mirror-creation time later resolves to a blocked/internal address, a deliberate, targeted setup rather than a drive-by. SSVC Technical Impact: total aligns with the C:H/I:H rating because a successful attack can force-push to and read responses from internal Git services. Net assessment: a genuine SSRF/TOCTOU bypass worth patching on internet-exposed or multi-tenant Gitea instances, but current telemetry (no POC, no KEV, low EPSS) indicates it is not under active or automated exploitation. Note one tension to verify: the official Gitea CVSS uses S:U, but reaching separate internal Git services is arguably a scope change (see assessed vector).

An attacker registers (or already has) a normal Gitea account, creates a repository they administer, and configures a push mirror pointing at a hostname that currently resolves to an allowed external address so it passes the [migrations] allow/block check. They then repoint that hostname's DNS to an internal-only Git service; on the next scheduled or manually triggered synchronization Gitea passes the stored address straight to git push, reaching the internal target and force-pushing the attacker's repository contents onto it. No public exploit code was identified at the time of analysis.