CVE-2026-96400 in Gitea
Summary
by MITRE • 10/06/2026
With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability in question represents a critical Server-Side Request Forgery (SSRF) flaw within the migration functionality of Gitea, specifically triggered when the ALLOWED_DOMAINS configuration parameter is set to permissive values such as an asterisk or hostname wildcards. This issue arises from a fundamental disconnect between domain-based allow-listing and IP-address based network restrictions. While the system includes a mechanism to block local networks via the ALLOW_LOCALNETWORKS setting, this protection relies on resolving hostnames to their corresponding IP addresses and checking them against a predefined list of private or reserved ranges. However, when a user initiates a migration using a URL that matches an entry in the ALLOWED_DOMAINS allow-list, the system accepts the request based solely on the hostname pattern without performing adequate validation of the resolved destination address. Consequently, even if local network access is theoretically disabled by configuration, the lack of strict IP verification allows requests to proceed to internal or reserved addresses.
This technical flaw specifically permits access to sensitive infrastructure endpoints that are typically isolated from external networks. The most notable example cited in reports involves the metadata service endpoint at 169.254.169.254, which is a standard link-local address used by major cloud providers such as AWS and Azure to expose instance metadata. By exploiting this vulnerability, an authenticated user with permission to start migrations can force the Gitea server to make HTTP requests to these internal endpoints. This capability enables attackers to retrieve sensitive configuration data, authentication tokens, or other credentials stored in the instance metadata store, effectively bypassing network segmentation controls that are intended to protect backend infrastructure from unauthorized access originating from application servers.
The operational impact of this vulnerability is severe, as it facilitates unauthorized information disclosure and potentially leads to full compromise of cloud instances if combined with subsequent exploitation steps. Attackers can leverage the retrieved credentials to escalate privileges within the cloud environment or pivot further into internal networks. This aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where a web server makes requests to unintended destinations based on user-supplied input. Furthermore, from an adversary perspective, this behavior maps directly to MITRE ATT&CK technique T1046, Network Service Discovery, as the attacker uses the vulnerable application to probe and enumerate internal network services that are not publicly accessible. The severity is compounded by the fact that the default configuration of Gitea does not include permissive ALLOWED_DOMAINS settings, meaning only instances with specific custom configurations are at risk, although such configurations are common in environments allowing migrations from various sources.
Mitigation strategies must focus on enforcing strict validation of both domain names and their resolved IP addresses. Administrators should ensure that the migration URL validation logic performs a final check against the target IP address after DNS resolution to confirm it does not fall within reserved, link-local, or private network ranges, regardless of whether the hostname matches an allow-list entry. This defense-in-depth approach ensures that even if domain-based filtering is bypassed through wildcard matching, the underlying network restrictions remain effective. Additionally, organizations should review their Gitea configurations and restrict ALLOWED_DOMAINS to specific, known safe domains rather than using broad wildcards where possible. Keeping Gitea updated to versions that include patches for this SSRF vulnerability is essential, as developers have addressed the logic gap by implementing more rigorous IP address validation during the migration process.