Gitea EUVD-2026-58153

Exploitation requires the ability to execute the gitea restore-repo CLI command directly on the host running the Gitea instance, which in practice means operator-level shell access to the server or the ability to supply a crafted archive to a trusted administrator who runs the command on the attacker's behalf. The attack is limited to files readable by the OS user account under which the Gitea process runs - if Gitea runs as a dedicated low-privilege user, files like /etc/shadow or root-owned SSH keys may be out of scope, while app.ini, process-user SSH keys, and cloud credential files typically remain accessible. The vulnerability is in a CLI maintenance command, not in any web-facing or API endpoint, and is therefore not exploitable over the network by a standard Gitea web user or API consumer. The limiting factors are: local/operator access required, the attacker must control archive contents supplied to restore-repo, and exfiltrated content scope is bounded by Gitea process user permissions.

No NVD CVSS vector was provided for this CVE, so all metric assessments below are independently derived from the description. The attack vector is local (AV:L) - exploitation requires running the restore-repo CLI command on the Gitea server host, which demands operator-level shell access or the ability to socially engineer a trusted operator into running a crafted archive. This high privilege prerequisite substantially constrains the realistic attack surface compared to a network-exploitable flaw. However, the confidentiality impact when exploited is high: arbitrary file read of any file accessible to the Gitea process, including app.ini (database passwords, secret keys), SSH host keys, TLS private keys, and cloud credential files. A fully functional proof-of-concept script was published by the researchers in the advisory GHSA-5ggr-2f2h-jmvm, confirming low attack complexity once access is obtained. EPSS data is unavailable for this CVE. The advisory tag 'RCE' appears to be a mislabeling - the demonstrated and confirmed impact is arbitrary file read and exfiltration, not direct code execution, though exfiltrated credentials could enable subsequent remote compromise of downstream systems. CISA KEV listing is absent, indicating no confirmed in-the-wild exploitation. Organizations with multiple operators or automated restore pipelines should treat this as a high-priority patch given the credential exposure potential.

An operator with shell access on the Gitea host constructs a zip archive containing a release.yml that sets the DownloadURL of a release asset to file:///etc/gitea/app.ini, then executes gitea restore-repo --zip-path ./malicious.zip --owner target-org --repo test-repo --units release. The Gitea process reads app.ini via os.Open() and stores its contents as a release attachment named output.txt, which the attacker subsequently retrieves unauthenticated or via the Gitea API using an admin token. A working bash proof-of-concept demonstrating this full chain was published by Isa Can and Yigit Ibrahim of Eresus Security.