Gitea EUVD-2026-58174

Exploitation requires the ability to initiate a repository migration or configure a pull mirror - i.e., access to Gitea's migration/mirror feature, which in most deployments means a registered user account (the published CVSS marks PR:N, appropriate for instances with open registration; on restricted instances an account is a real prerequisite - authentication requirements should be confirmed against your instance config). The attacker must control DNS for the target hostname (for the rebinding vector) or an endpoint that issues a redirect to a restricted address (for the missing-re-validation vector), and there must be an internal/link-local service worth reaching from the Gitea host. Limiting factors: the outbound fetch only returns data the migration/mirror path exposes back to the attacker; hosts with strict egress firewalling to internal ranges, IMDSv2-only metadata, or migrations locked to admins substantially reduce practical exploitability. Affected only on versions ≤1.26.4.

Signals here are mixed and should be read carefully. The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H) yields 9.1 and implies unauthenticated network exploitation, but the migration/mirror workflow in a typical Gitea deployment requires an authenticated account to initiate - verify against your instance's registration/self-service settings, because on an open-registration server PR:N is effectively true, while on a locked-down internal instance the practical privilege requirement is higher. SSVC reinforces a nuanced picture: Exploitation is 'none' (no observed activity, consistent with the very low 0.15% EPSS and no KEV listing), yet Automatable is 'yes' and Technical Impact is 'total', meaning that if it is exploited it can be done at scale with full impact on the reachable internal target. This is not a hype-driven high-CVSS-but-low-real-risk case: SSRF into cloud metadata endpoints or internal admin services is a well-trodden, high-value attack, so even a mid-sized operator running Gitea for internal teams should treat this as an urgent patch rather than a routine one. The low EPSS reflects absence of a public exploit today, not low intrinsic severity; do not defer solely on that basis.

An attacker with (or able to self-register) a Gitea account creates a repository migration or mirror pointing at a hostname they control. The hostname passes Gitea's allow-list check when first resolved, then rebinds to an internal address (or 302-redirects to one) so the server fetches from cloud metadata or an internal admin service and the attacker reads the returned content. No public exploit code was identified at time of analysis, but the technique is well-known and, per SSVC, automatable.