CVE-2026-70357 in Gitea
Summary
by MITRE • 10/06/2026
Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess independently resolves the hostname when connecting. An attacker who can start a migration and control the destination's DNS can change the address between validation and connection to reach a blocked internal address. The affected path is the Git clone operation; validation in the migration HTTP client's dialer does not protect the independently connecting Git subprocess.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability described represents a classic Time-of-Check-to-Time-of-Use (TOCTOU) race condition within Gitea’s repository migration functionality, specifically affecting how external repositories are cloned into the system. The core technical flaw lies in the architectural separation between the application-level validation logic and the underlying Git subprocess execution environment. When an administrator or authorized user initiates a migration from an external source, Gitea performs security checks by validating the destination hostname against configured network allowlists and blocklists using its internal HTTP client dialer. This initial check is designed to prevent connections to unauthorized or dangerous internal addresses that could lead to server-side request forgery (SSRF) attacks or data exfiltration. However, this validation occurs only at the point of initiating the migration process via Gitea’s own network stack.
Once the validation passes, Gitea invokes a Git subprocess to perform the actual clone operation. Crucially, this Git binary operates independently and performs its own DNS resolution when establishing connections to remote repositories. The security boundary established by Gitea’s application-layer checks does not extend into the environment of the spawned process in terms of real-time network filtering. An attacker with the ability to initiate a migration request can exploit this gap if they also control or influence the Domain Name System (DNS) records for the target hostname. By manipulating DNS responses, an attacker can change the IP address associated with a permitted domain name between the moment Gitea validates the hostname and the moment Git attempts to connect. This allows the connection to be redirected from a public, allowed host to a private, internal network address that was originally blocked by the allowlist.
The operational impact of this vulnerability is severe, as it effectively bypasses SSRF protections intended to isolate the Gitea server from its internal network infrastructure. Successful exploitation could enable an attacker to probe internal services, access sensitive data stored on internal servers, or potentially interact with other systems within the organization’s private network that are not exposed to the public internet. This undermines the principle of least privilege and network segmentation strategies often employed in secure deployments. The vulnerability highlights a critical oversight where application-level security controls were assumed to cover all aspects of external communication without accounting for the independent behavior of underlying system utilities like Git, which may have their own networking stacks or configurations that do not inherit the parent process’s restrictions.
To mitigate this risk, immediate remediation should focus on ensuring that network validation is performed at every stage of connection establishment, including within the context of subprocess execution. This can be achieved by configuring the underlying operating system to restrict outbound connections from the Git user account using firewall rules such as iptables or nftables, thereby enforcing network policies regardless of how the process initiates its requests. Additionally, Gitea administrators should ensure they are running a patched version that addresses this TOCTOU flaw, if available in their specific release track. Long-term architectural improvements involve implementing strict egress filtering at the container or host level and avoiding reliance solely on application-level hostname validation for security-critical operations involving external network connections. This incident underscores the importance of defense-in-depth strategies where multiple layers of control are required to secure complex software interactions with external systems.