The Gitea restore-repo CLI command restores repositories from dump archives and parses pull_request.yml files. The Head.CloneURL field from these files is used to add git remotes and fetch from them without proper validation because the CheckAndEnsureSafePR function is called with an empty commonCloneBaseURL parameter. This causes the safety check to be effectively disabled since strings.HasPrefix with an empty prefix always returns true. As a result, arbitrary URLs controlled by an attacker can be used in git fetch commands executed by the server. This enables SSRF attacks against internal or cloud metadata endpoints and disclosure of local git repositories via file:// URLs. The issue is confirmed in versions 1.26.4, release/v1.27, and main branches. Remote code execution via git transport helpers was tested and ruled out.

An attacker who can convince an administrator to run the restore-repo command on a malicious dump can cause the Gitea server to perform git fetch operations against arbitrary URLs. This allows SSRF attacks targeting internal-only services or cloud metadata endpoints accessible from the Gitea host. Additionally, it can disclose local git repositories accessible via file:// URLs readable by the Gitea process. There is no known remote code execution impact. The vulnerability requires local or administrative access to run restore-repo with a crafted dump.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid running the restore-repo command on untrusted or unauthenticated dump archives. Validate or sanitize pull_request.yml files before use to ensure Head.CloneURL fields do not contain attacker-controlled URLs. Monitor vendor announcements for patches addressing this issue.