CVE-2026-57894

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

Published

2026-07-21

Modified

2026-07-21

Aliases

GHSA-82f7-87hm-852x

Sources

github-advisory

Summary

# Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration ## Summary 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. ## Technical Root Cause Analysis The root cause is a validation/enforcement mismatch across a trust boundary. This should be treated as a product security issue rather than a pure deployment misconfiguration: deployment choices influence reachability and impact, but Gitea applies policy to the originally submitted URL while the Git subprocess is allowed to reach a different effective URL after redirection. Gitea validates the original migration URL: - `C:\Users\One\Desktop\gitea_new\gitea\routers\web\repo\migrate.go:180` parses the submitted web migration clone address. - `C:\Users\One\Desktop\gitea_new\gitea\routers\web\repo\migrate.go:182` calls `migrations.IsMigrateURLAllowed`. - `C:\Users\One\Desktop\gitea_new\gitea\routers\api\v1\repo\migrate.go:101` parses the submitted API migration clone address. - `C:\Users\One\Desktop\gitea_new\gitea\routers\api\v1\repo\migrate.go:103` calls `migrations.IsMigrateURLAllowed`. The URL validator resolves and checks the initially supplied host: - `C:\Users\One\Desktop\gitea_new\gitea\services\migrations\migrate.go:44` defines `IsMigrateURLAllowed`. - `C:\Users\One\Desktop\gitea_new\gitea\services\migrations\migrate.go:75` rejects unsupported schemes. - `C:\Users\One\Desktop\gitea_new\gitea\services\migrations\migrate.go:79` extracts the host. - `C:\Users\One\Desktop\gitea_new\gitea\services\migrations\migrate.go:85` performs DNS resolution. - `C:\Users\One\Desktop\gitea_new\gitea\services\migrations\migrate.go:86` enforces the allow/block list on the originally resolved host. After this validation, the actual repository data transfer is delegated to Git: - `C:\Users\One\Desktop\gitea_new\gitea\services\repository\migrate.go:93` calls `gitrepo.CloneExternalRepo` with `opts.CloneAddr`. - `C:\Users\One\Desktop\gitea_new\gitea\modules\gitrepo\clone.go:13` delegates to `git.Clone`. - `C:\Users\One\Desktop\gitea_new\gitea\modules\git\repo.go:123` constructs a `git clone` command. - `C:\Users\One\Desktop\gitea_new\gitea\modules\git\repo.go:125` conditionally sets only `http.sslVerify=false`. - `C:\Users\One\Desktop\gitea_new\gitea\modules\git\repo.go:154` appends the source and destination arguments. No equivalent network policy is applied to the final URL reached by Git after HTTP redirection. The protected migration HTTP client exists for service-specific migration API calls, but it is not used for the raw Git clone/

Affected packages

Remediation: Upgrade to 1.27.0 or later.

References

• https://github.com/advisories/GHSA-82f7-87hm-852x