Description

Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-13T17:17:25.970Z",
  "pubdate": "2026-08-13T17:17:25.970Z",
  "executiveSummary": "A vulnerability exists in repository migration features where URL allow and block list validations are performed prior to following Git HTTP redirects. This architectural flaw allows an attacker to bypass domain restrictions by supplying an initially validated external URL that subsequently responds with an HTTP redirect pointing to internal resources or restricted network locations.\nThe primary impact of this flaw is Server-Side Request Forgery (SSRF) leading to internal Git repository exfiltration. Attackers can leverage this behavior to access internal metadata services, local network infrastructure, or sensitive internal repositories that should otherwise be isolated from external network access.\nThe affected systems include platforms supporting automated repository migration and import functionalities via Git protocols. Risk implications are severe, as unauthorized entities can extract proprietary source code and internal intellectual property by exploiting the trust relationship between the migration engine and HTTP redirection handlers.\nAttacker capabilities include arbitrary outbound HTTP request generation and the ability to force the migration service to interact with arbitrary internal network endpoints. Exploitation requirements typically involve the ability to host a malicious redirect server or compromise an allowed domain to issue HTTP redirection responses targeting internal IP addresses or restricted URIs.",
  "technicalDetails": "The root cause of the vulnerability stems from a validation sequence flaw within the repository migration subsystem. Specifically, security controls enforce URL allow and block list checks strictly at the initial entry point of the migration request, failing to re-evaluate destination URLs after processing protocol-level HTTP redirects.\nWhen a user initiates a repository migration, the application parses the provided source URL and evaluates it against configured security policies, such as validating that the domain resides on an approved allow list or does not match prohibited internal network ranges.\nOnce the initial validation passes, the migration engine initiates an HTTP connection to fetch the remote Git repository. If the malicious server responds with an HTTP redirect status code (such as 301, 302, 307, or 308) coupled with a Location header pointing to an internal target—such as a loopback address, link-local address, or internal metadata service—the HTTP client library automatically follows the redirection chain.\nBecause the validation check is not executed recursively on subsequent redirect hops, the application proceeds to issue requests to the internally targeted resource. During the Git handshake or clone process, sensitive internal data or repository contents returned by the internal endpoint are processed and potentially exposed or logged within the migration context.\nThe vulnerable components involve the network request handling routines and URL filtering logic within the repository import and migration modules. The attack flow relies entirely on the application's native behavior of following HTTP redirects without enforcing secondary validation gates on intermediate or final destination URLs.\nExploitation requires network exposure of the migration feature to user-supplied input. Depending on the specific application configuration, authentication and baseline privileges may be required to initiate a repository migration, though the post-exploitation impact remains critical due to the unauthorized exposure of internal network resources and sensitive codebases."
}