Gitea Repository Migration SSRF and Internal Git Repository Exfiltration

A critical server-side request forgery (SSRF) vulnerability has been identified in Gitea, affecting versions where repository migrations are enabled by default. This flaw enables an authenticated, low-privileged user to bypass Gitea's URL allow/block validation and exfiltrate internal Git repositories. The issue stems from a trust boundary mismatch: Gitea validates the initial public URL provided for repository migration, but the subsequent git clone or git fetch --tags operation, delegated to the Git command-line client, automatically follows HTTP redirects. Git's default http.followRedirects=initial setting allows an attacker to provide a public, seemingly benign URL that redirects the Gitea server to an internal Git HTTP(S) endpoint (e.g., http://127.0.0.1:PORT/internal.git/). This results in the Gitea server cloning internal code, configuration, and potentially sensitive credentials into an attacker-controlled repository. The vulnerability impacts all Gitea instances with repository migrations enabled, posing a significant risk for organizations hosting internal development resources, with persistent data exfiltration possible via pull mirrors continuously updating the attacker's repository.

Attack Chain

1. An authenticated, low-privileged user gains access to a Gitea instance where repository migrations are enabled.
2. The attacker sets up a public HTTP endpoint (e.g., https://attacker.example/public.git) controlled by them and configured to issue an HTTP redirect.
3. The attacker configures this public endpoint to redirect the initial Git discovery request (e.g., GET /repo.git/info/refs?service=git-upload-pack) to an internal target, such as http://internal-git.company.local/team/private.git/info/refs.
4. The attacker initiates a repository migration or mirror creation in Gitea, providing the public https://attacker.example/public.git URL.
5. Gitea's internal validation checks and allows the attacker.example host, then invokes git clone --mirror or git fetch --tags using the provided public URL.
6. The git command-line client follows the HTTP redirect, establishing a network connection to the internal Git repository http://internal-git.company.local/team/private.git (or 127.0.0.1).
7. The contents of the internal repository are cloned by the Gitea server into the attacker's newly created repository on the Gitea instance.
8. The attacker accesses the imported repository, searching for sensitive source code, CI/CD secrets, cloud credentials, Kubernetes kubeconfigs, or production configurations.

Impact

The primary impact of this vulnerability is the unauthorized exfiltration of sensitive internal Git repositories, including proprietary source code, configuration files, and critical credentials such as CI variables, cloud access keys, Kubernetes kubeconfigs, deployment SSH keys, and API tokens. For internet-accessible Gitea instances with repository migrations enabled, this poses a high risk of significant data breach. If an attacker leverages pull mirrors, the exfiltration can become persistent, continuously updating the attacker's repository with new internal commits. Although not a direct Remote Code Execution (RCE) in Gitea itself, the stolen credentials can be subsequently used in a post-exploitation chain to gain code execution in CI/CD pipelines, cloud environments, container registries, deployment hosts, or orchestration infrastructure, potentially leading to widespread infrastructure compromise. The vulnerability affects any organization using Gitea to host internal development resources, particularly if valuable intellectual property or sensitive infrastructure secrets are stored within Git repositories.

Recommendation

• Disable repository migration and pull mirrors in Gitea if they are not essential for your operational requirements, to mitigate both one-time and persistent exfiltration risks.
• Deploy the provided Sigma rules to your SIEM to detect suspicious git process network connections to internal IP addresses or private ranges.
• Review Gitea audit logs for unusual repository migration attempts originating from external URLs followed by internal network activity.
• Implement strict network segmentation and egress filtering for your Gitea server to prevent it from initiating connections to internal development infrastructure or sensitive systems that it should not access.