Gitea EUVD-2026-93909

Attacker must hold an authenticated Gitea account (≤1.27.3) with privilege to create repository migrations or pull mirrors. Exploitation requires the attacker to control a hostname whose DNS returns multiple answers so that the IP validated by the egress/SSRF check differs from the IP Git actually connects to (a TOCTOU multi-answer DNS race). The intended internal target must be a reachable Git or HTTP endpoint on the server's network. Limiting factors: requires authentication and migration/mirror permissions (not anonymous), depends on a non-deterministic DNS resolution race rather than a deterministic request, and is fixed in Gitea 28.0.0; disclosure of internal response content additionally relies on error messages being surfaced to the user.

All exploitation-likelihood signals point LOW. The official CVSS is 4.3 (Medium), EPSS is 0.12% at the 2nd percentile (very low predicted exploitation), there is no CISA KEV listing, and the SSVC decision framework returns Exploitation: none / Automatable: no / Technical Impact: partial - a consistent picture of a low-priority, non-wormable issue. No public exploit code is present in the provided references (they are vendor patches, release notes and advisories, not a POC). The one notable CONFLICT is between the official CVSS impact (C:L/I:N/A:N) and the description, which explicitly states the attacker can be 'reading from and writing to reachable internal Git or HTTP endpoints' - the write capability implies an integrity impact that the published vector scores as I:N, so the official score likely understates impact; this should be verified against the Gitea advisory (GHSA-6g2h-xpg3-rm48). Also note the attack is a TOCTOU / multi-answer-DNS race, which raises real-world attack complexity above the AC:L in the published vector. Net: a genuine authenticated SSRF worth patching, but not an emergency - no evidence of active or automatable exploitation, and a fix is available in Gitea 28.0.0.

A low-privileged user with permission to create repository migrations or pull mirrors submits a clone URL whose hostname is attacker-controlled and returns multiple DNS answers; the egress validation check approves one (safe-looking) address while Git subsequently connects to a different, internal address, letting the server reach internal Git/HTTP services. The attacker then reads internal content directly or harvests it from migration/mirror error messages (CWE-209). No public exploit code was identified at time of analysis, and the attack depends on a non-deterministic DNS race.