CVE-2026-57894: Gitea: Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration

Gitea validates the user-supplied repository migration URL, but the actual clone and later mirror fetch operations are performed by the Git command-line client without disabling HTTP redirects. Git’s default http.followRedirects=initial follows the first redirect and then uses the redirected URL as the base for later repository object requests.

This creates a URL-policy bypass, SSRF, and repository exfiltration primitive. A low-privileged authenticated user can submit an allowed public Git URL that redirects the Gitea server to an otherwise blocked or internal Git HTTP(S) endpoint. Local validation confirmed that Git followed a first-hop redirect to 127.0.0.1, fetched Git objects, and completed the clone; git -c http.followRedirects=false clone blocked the same path.

The main impact is internal Git repository exfiltration into an attacker-controlled Gitea repository. Pull mirrors increase risk because scheduled git fetch --tags operations can keep following the redirect and collect future internal commits.

This is High severity by default for internet-accessible instances with migrations enabled, and can become Critical where internal repositories contain deploy keys, CI/CD secrets, cloud credentials, Terraform state, kubeconfigs, signing material, or production configuration. Direct unauthenticated exploitation, direct Gitea server RCE, arbitrary file:// import, and default Actions runner execution are not confirmed.

A local safe PoC was run with two HTTP services:

• Redirector service: represents the attacker-controlled public URL.
• Target service: represents an internal Git HTTP repository on loopback.

Observed behavior:

• git clone was invoked against the redirector URL.
• The redirector returned a first-hop HTTP redirect to the internal target URL.
• Git followed the redirect.
• The internal target received Git requests for:
• /info/refs
• /HEAD
• object paths required for clone completion
• The clone completed successfully.
• The cloned repository contained the expected file content from the internal target repository.

The local PoC result showed:

code: 0
redirector hit count: 1
target hit count: 5
cloned content: "internal repo data via redirected git clone"

Mirror fetch behavior was also validated locally:

• A bare mirror remote was configured to point at the redirector URL.
• git fetch --tags origin followed the redirect into the internal target.
• The target received object requests.
• The mirror fetched the expected branch reference successfully.

The mirror PoC result showed:

code: 0
target object requests observed: 5
hasFetchedBranchRef: true

Mitigation behavior was validated locally:

• The same clone was run with git -c http.followRedirects=false clone.
• Git failed on the redirect with an HTTP 302 error.
• This confirms that disabling Git HTTP redirects blocks the validated redirect SSRF path.

The failed mitigation test behavior was:

fatal: unable to access '<redirector-url>': The requested URL returned error: 302

Negative validation:

• An HTTP redirect to file:// was attempted.
• Git refused the redirected local-file protocol with Protocol "file" disabled (in redirect).
• Based on this validation, this report does not claim arbitrary local filesystem read or local repository import through file:// redirection.

Validation scope:

• The local PoC validates the security-critical network sink used by the Gitea migration path: Git clone/fetch follows the redirect and retrieves repository objects from the redirected internal target.
• The source review validates that Gitea’s migration handlers pass the validated clone URL into that Git clone/fetch path without disabling HTTP redirects.
• A full disposable Gitea UI/API end-to-end import proof was not executed as part of this report. If additional assurance is required before external submission, the highest-value next validation step is to run a temporary Gitea instance, create a low-privileged user, submit the redirector URL through POST /repo/migrate or POST /api/v1/repos/migrate, and confirm that the resulting attacker-owned Gitea repository contains the internal repository content. For mirror mode, add a new commit to the internal target and confirm a later mirror sync imports it.