Gitea performs URL validation on user-supplied repository migration URLs to enforce allow/block policies. However, the actual cloning and mirror fetch operations are executed by the Git command-line client, which by default follows HTTP redirects (http.followRedirects=initial). This behavior allows an attacker to submit a permitted public Git URL that redirects to an internal or blocked Git HTTP(S) endpoint, bypassing Gitea's URL validation. The Git client follows the redirect and fetches repository objects from the internal endpoint, enabling repository exfiltration. This mismatch between Gitea's validation of the original URL and Git's redirect-following behavior creates a server-side request forgery (SSRF) and data exfiltration vector. The vulnerability affects migration and mirror fetch operations, with mirrors increasing risk due to scheduled fetches that continue following redirects. The root cause is a trust boundary enforcement mismatch where Gitea does not apply network policy to the final URL after redirection. No patch or official fix is indicated in the provided data.

An authenticated low-privileged user can exfiltrate internal Git repositories by exploiting HTTP redirects during repository migration or mirror fetch operations. This can lead to unauthorized disclosure of sensitive internal repositories, including those containing deploy keys, CI/CD secrets, cloud credentials, Terraform state, kubeconfigs, signing material, or production configuration. The vulnerability does not confirm direct unauthenticated exploitation, remote code execution, or arbitrary file import. The risk is highest for internet-accessible Gitea instances with migration enabled and internal repositories containing sensitive data.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, administrators should consider disabling repository migration and mirror fetch features for untrusted users or restrict migration URLs to trusted hosts without redirects. Monitoring and restricting Git client behavior regarding HTTP redirects may also help mitigate risk. Review deployment configurations to limit internal network exposure from Gitea servers.