AI analysis
Gitea can skip its local-network restrictions during repository migrations when [migrations] ALLOWED_DOMAINS is configured. A hostname on that allow list is accepted without checking the address it resolves to, so a user who can start migrations and control DNS for an allowed name can make it resolve to loopback or a private address and reach internal services from the Gitea server, bypassing ALLOW_LOCALNETWORKS = false. The stated impact is disclosure of data from those internal services, not a change to integrity or availability. Instances that have not configured ALLOWED_DOMAINS are not affected by this bypass. No public proof of concept is known, and the issue is not listed in CISA KEV.
What to do: Apply the vendor patch for this issue as soon as it is available for your Gitea release; no fixed version is named in the advisory data. Until then, limit which accounts can start repository migrations, and treat [migrations] ALLOWED_DOMAINS as insufficient protection while ALLOW_LOCALNETWORKS is false. After upgrading, confirm that migration fetches still reject hostnames that resolve to loopback or private addresses.
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostname could make it resolve to loopback or private addresses and bypass `ALLOW_LOCALNETWORKS = false`, reaching internal services from the Gitea server. Instances without `ALLOWED_DOMAINS` configured are not affected by this specific bypass.