Gitea CVE-2026-101027

Requires all of: (1) the optional [migrations] ALLOWED_DOMAINS allow-list is configured - the description states instances without it are not affected; (2) ALLOW_LOCALNETWORKS=false (the control being bypassed); (3) an authenticated account with permission to start repository migrations (CVSS PR:L); and (4) attacker control over the DNS resolution of a hostname already present in ALLOWED_DOMAINS, so it can be pointed at loopback or private addresses. Limiting factors that reduce realistic risk: the allow-list feature is not enabled by default, exploitation needs valid credentials with migration rights, and the attacker must control authoritative DNS for an allow-listed name - none of which apply to a default installation.

This is a server-side request forgery / network-restriction bypass in Gitea, not an authentication bypass as the input tag suggests. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, 7.7 HIGH) is network-reachable but explicitly authenticated (PR:L): the attacker must already have an account permitted to start repository migrations. The scope change (S:C) and C:H correctly reflect that successful exploitation pivots from Gitea into separate internal systems. Real-world risk is materially lower than the raw 7.7 implies because exploitation is gated behind two conditions the attacker does not fully control: the instance must have the optional [migrations] ALLOWED_DOMAINS allow-list configured (the description states instances without it are not affected), and the attacker must control DNS for a hostname already on that allow-list. No EPSS score, KEV listing, or public POC is present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. I assess AC:H rather than the input's AC:L, since requiring an allow-listed hostname under attacker DNS control is a condition beyond the attacker's control and not present in default deployments. CWE is listed as N/A in the input but this is functionally CWE-918 (SSRF) via a TOCTOU/DNS-rebinding allow-list gap. Net: a credible internal-pivot risk for the subset of instances using ALLOWED_DOMAINS, but a configuration-dependent, authenticated issue rather than a mass-exploitable unauthenticated flaw.

An authenticated Gitea user with migration privileges, on an instance configured with [migrations] ALLOWED_DOMAINS, sets DNS for a hostname on the allow-list to resolve to 127.0.0.1 or an RFC1918 address. They start a repository migration against that hostname; Gitea accepts it on name match without re-checking the resolved address, so the outbound request reaches internal services despite ALLOW_LOCALNETWORKS=false. No public exploit code is identified at time of analysis.