Sending the same patch twice gives attackers shell access to Gitea servers

CISA added CVE-2026-60004 to its catalogue of known exploited vulnerabilities on 25 August 2026, confirming that the Gitea flaw is being used in attacks. Gitea published its advisory on 28 July and fixed the flaw in version 1.27.1. Every release from 1.17 up to 1.27.1 is affected. A user with write access to a repository can submit a crafted patch and have shell commands run as the system account Gitea runs under. Where open registration is enabled, registering an account and creating a repository is enough to obtain that access.

The mechanism sits in the diffpatch endpoint. Send the same patch twice and it collides with itself, and Git resolves that collision by writing the file to disk even though the operation asked to stay in the index. The clone is bare, so its root is the directory Git keeps its own data in, and the file hooks/post-index-change therefore becomes a live Git hook running as the Gitea system account. Gitea notes that its proof-of-concept stores the result in Git objects and a separate branch rather than sending it off the server, so the attack needs no outbound connection. The flaw is classified as code injection, CWE-94, and the advisory scores it 9.8 out of 10 under CVSS 3.1.

What this means for you if you run Gitea yourself

If you have a Gitea server running, the window for planned maintenance has closed. The CISA listing means someone is already exploiting the flaw, and the date in the catalogue records when CISA added it, not when the attacks began. Our assessment is that a self-hosted Gitea is a tempting target no matter how small the installation is. The source code sits there, the secrets in app.ini sit there, and the system account usually reaches both.

The setting that decides how exposed you are is open registration. Leave it on with the server answering from the internet, and nobody needs to obtain a password first. Getting from casual visitor to command execution on the server then takes three ordinary actions in the interface. The question we think you should ask today is not whether anyone has tried. It is what your system account can actually reach if someone succeeded. Gitea itself lists app.ini, the database connection, the mounted repositories and credentials for integrations as being within range.

Berigo recommends

• Upgrade to Gitea 1.27.1 or later. Everything from 1.17 onwards is affected.
• Turn off open registration on servers that answer from the internet, unless you have a good reason to keep it on.
• Review who holds write access to your repositories, and remove it wherever it is no longer needed.
• Look for files under hooks in the repositories on the server, and for branches and Git objects you cannot account for.
• If the server has been left unpatched and open to the internet, treat it as possibly compromised. Rotate the secrets in app.ini and the database password.