CVE-2026-60004: Gitea's Hook Injection Flaw Is Under Active Attack — Patch to 1.27.1 Now

If your team runs a self-hosted Gitea instance instead of paying for GitHub or GitLab, stop reading and go check your version number. CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026, issuing a federal agency patching deadline of August 28. Attacks are already automated, the exploit takes roughly eleven seconds to execute end-to-end, and default Gitea configurations make it far too easy for a scanner to walk right in.

What Gitea Is — and Why You Should Care

Gitea is a lightweight, open-source Git hosting platform written in Go. It ships as a single binary, runs on virtually anything, and has become the go-to self-hosted alternative for development shops, agencies, and organizations that want their source code on their own infrastructure rather than a third-party cloud. That self-hosted advantage is also the risk: patches don't apply themselves, and Gitea doesn't push alerts the way a SaaS vendor might.

The vulnerability affects all Gitea versions from 1.17 through 1.27.0. Gitea 1.27.1 shipped the fix in late July 2026; 1.27.2 is the current secure release. If your instance predates 1.27.1 and has been running quietly in the corner of a VM, it is now a liability.

How the Exploit Works

CVE-2026-60004 is a code injection vulnerability (CWE-94) in Gitea's diffpatch API endpoint. The endpoint is designed to apply patches to repositories — it's a legitimate feature. The flaw lies in how it processes that input: an attacker with write access to a repository can submit a crafted patch that plants an executable Git hook into the repository. Once that hook is in place, it runs arbitrary shell commands as the Gitea OS service account.

That service account typically has access to everything Gitea touches: repository data, configuration files, database credentials, OAuth tokens, and SSH keys. One successful hook execution hands an attacker the keys to every project on your instance.

The worst part of the default configuration story: Gitea enables open user registration out of the box, with no email confirmation or CAPTCHA required. That means an automated scanner can register an account, create a repository, push a malicious patch to the diffpatch endpoint, and trigger the hook — all without any prior access. The security researcher who documented a real-world incident noted the active portion of the attack chain took about eleven seconds.

What Attackers Are Doing With It

Confirmed in-the-wild attacks have been deploying cryptocurrency-mining software. In one documented case, a compromised Gitea instance was quickly consuming more than 70 percent of server CPU. The mining payload is nasty but relatively detectable; the more dangerous scenario is a targeted attacker who takes the same foothold, exfiltrates source code and credentials silently, and leaves no obvious performance indicator behind.

A related Gitea flaw, CVE-2026-20896, was actively exploited in early July 2026 and still does not appear in CISA's KEV catalog — meaning Gitea has been a live target for nearly two months now, across multiple vulnerabilities, with attackers actively automating reconnaissance.

What You Need to Do

• Upgrade immediately to Gitea v1.27.1 or v1.27.2. This is the only complete fix. Check your running version at /admin/self-check or via gitea --version.
• Disable open registration if you don't need it. In app.ini, set DISABLE_REGISTRATION = true under [service]. For most teams with a known set of contributors, this should have been the default from day one.
• Audit Git hooks across all repositories. Look for anything unexpected in .git/hooks/ directories on the server. A hook you didn't create is a hook an attacker did.
• Review your service account's OS permissions. The Gitea process should run as a dedicated, low-privilege user — not as root, and not as a user with write access to unrelated directories.
• Check CPU utilization and outbound network traffic for the period before patching. Cryptominers leave signatures in resource metrics and DNS queries.
• Rotate any secrets the Gitea service account could have touched: database passwords, SSH deploy keys, OAuth application secrets, and any credentials stored in repository configuration files.

The Bigger Pattern

This isn't the first time a self-hosted dev platform has burned organizations that let updates slip. The CVE-2026-20896 exploitation in July went largely unnoticed outside security circles. Self-hosted tooling — Gitea, Gogs, Forgejo, Jenkins, Nexus — often runs without the same update discipline applied to public-facing web servers, partly because it's "internal" and partly because nobody broke the deployment. But attackers have gotten very good at finding internet-exposed admin interfaces on non-standard ports, and dev infrastructure is now a first-class target for both credential theft and supply-chain staging.

CVSS 9.8, active exploitation, CISA KEV — that combination means there is no "we'll patch it next sprint." The exploit is automated and the attackers are already running.

At Falcon Internet, source code infrastructure sits behind the same monitoring discipline as everything else we manage — because a compromised build pipeline is often a worse outcome than a compromised web server.