A critical remote code execution flaw in Gitea is being actively exploited, and the clock is ticking. CVE-2026-60004 (CVSS 9.8) lets attackers gain shell access to self-hosted Gitea instances in as little as 11 seconds — with zero credentials on a default install. CISA added it to the Known Exploited Vulnerabilities catalog on August 25, with a mandatory federal patch deadline of August 28. If you run Gitea, that date is not just for government agencies.
How the Attack Works
The vulnerability lives in Gitea’s diffpatch endpoint, which processes repository patches using Git commands. The exploit is surprisingly elegant in a terrible way: send the same malicious patch to the endpoint twice. This creates an “add/add collision” — a merge conflict that triggers Git’s three-way fallback mechanism, which writes the file path embedded in the patch directly to disk.
Here is where the default Gitea configuration turns a bad bug into a catastrophe. The temporary working directory is a bare clone of the repository. That means a crafted path like hooks/post-index-change lands not in a sandboxed workspace, but in Git’s live hook directory. Git marks the file executable on write and then runs it automatically while updating the index. Every command in that hook executes as the Gitea service account.
The result: arbitrary shell command execution, no authentication required, triggered by a file write that Git itself performs.
No Credentials Needed on Default Installs
Gitea ships with open self-registration enabled, no email confirmation, and no CAPTCHA. A developer named Andrey documented exactly what that combination looks like in practice when attackers show up: an automated scanner registered an account on his unpatched Gitea instance, created a repository, and triggered the full exploit chain in approximately 11 seconds. The dropper that arrived cleared competing processes, fetched architecture-specific binaries, and began mining cryptocurrency.
This is not a sophisticated nation-state attack. It is a script scanning the internet for low-hanging fruit, and Gitea instances on default configurations are exactly that.
What Is Actually at Risk
When an attacker executes code as the Gitea service account, the damage potential runs deep. Gitea’s main configuration file, database credentials, OAuth tokens, and integration secrets are all accessible at that privilege level. Downstream CI/CD pipelines fed by the compromised server are also exposed — an attacker who owns your Git server can poison your build artifacts before they reach production.
CISA’s bulletin notes that roughly 34,000 Gitea instances were internet-exposed as of earlier this year. Not all of them have patched. The ones running versions 1.17 through 1.27.0 with open registration are exactly the profile this scanner is hunting.
What to Do Now
Upgrade to Gitea 1.27.2 immediately. Version 1.27.1 was the initial patch, but 1.27.2 is the current stable release. If your instance was unpatched and internet-exposed, assume compromise and rotate everything: configuration secrets, database credentials, OAuth tokens, and any integration keys the service account could reach.
Then tighten your defaults:
- Disable open self-registration if your team does not need it
- Enable email confirmation for new accounts
- Audit repository write access — the exploit only requires write access to one repository
- Check your
hooks/directories for unexpected files - Look for unexpected outbound connections or anomalous processes running as the Gitea user
A Pattern Worth Noting
This is not Gitea’s first serious CVE this year. ByteIota covered CVE-2026-59774 — a file read escalation to RCE — three weeks ago, and Gitea’s 1.27 release in July patched 45 CVEs in a single drop. SecurityWeek calls this “the second Gitea vulnerability exploited in recent months.” A third CVE from early July — CVE-2026-20896 — has not yet landed in CISA’s catalog.
Self-hosted Git has a reputation as the more controlled, secure alternative to SaaS platforms. That reputation is not holding up. If you are maintaining an internet-exposed Gitea instance, it deserves the same patching urgency as your public web services — because right now, attackers are treating it that way.













