Gitea patches a code-injection bug exploited in 11 seconds against self-hosted instances

August 25, 2026. CVE-2026-60004. August 28. The CISA added a critical code-injection flaw in Gitea, the Go-based self-hosted Git forge, to its KEV catalog with confirmed in-the-wild exploitation. U.S. federal agencies have until August 28, 2026 to patch. The bug lets an attacker with ordinary write access to a repository execute arbitrary commands as the forge’s OS user — and, with open registration enabled, do it in seconds against anyone, no targeting required.

What the flaw allows

CVE-2026-60004 hits Gitea’s diffpatch endpoint. By abusing it, an attacker can install and then execute a Git hook from repository-controlled content. The maintainers’ own wording is blunt: “An attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user.”

The worst case arrives when open registration is on. An unauthenticated visitor signs up, creates a repository and triggers the exploit chain without ever being invited. The bug was privately disclosed to the maintainers, but the published advisory shipped a proof-of-concept exploit, which sped up weaponization. Depending on deployment isolation and the privileges of the OS user, exploitation exposes the main configuration file, environment secrets, database credentials and OAuth integration tokens.

The exploitation, on a stopwatch

The first documented exploitation comes from a post on Habr by a developer whose instance was compromised. The server ran an outdated version of Gitea with open registration and no email confirmation or CAPTCHA. An automated scanner registered an account, created its own repository and triggered the exploit.

The timeline is arresting: the active part of the attack took about 11 seconds. The code first wrote a “proof” of remote code execution back into a Git branch, then downloaded a universal shell-loader, then a crypto-miner-like dropper that fought for CPU. Because Gitea ran in Docker without privileges, the malicious process did not survive a restart, and no persistence was found — no cron, no systemd, no added SSH keys.

That it was a miner and not a code thief should not be comforting: it is the signature of a broad automated scan, not a targeted attack. The same entry point, used by a patient operator, would exfiltrate the repositories before being noticed.

The episode also exposes a gap in how self-hosted operators monitor. The developer was alerted not by a security tool but by a hosting provider flagging sustained high CPU. An instance that quietly serves a miner for weeks is indistinguishable from a healthy one on the surface — which is why outbound network monitoring and CPU baselines belong in the baseline for any self-hosted service, not just forges.

Why self-hosting widens the surface

A self-hosted forge concentrates three risks that managed offerings absorb on your behalf. First, you are your own patch team: no one upgrades Gitea for you, and the fixing version 1.27.1 shipped in late July — a month of exposure for anyone who missed it. Second, open registration is often left on “to make contributions easy”, which turns a post-authentication flaw into a pre-authentication one. Third, a forge by nature holds the most valuable thing a team owns: source code and the secrets that ride along with it.

Nor is this flaw an outlier: Gitea was already at the center of an arbitrary file read that escalated to RCE earlier this year. The cadence is accelerating as self-hosted forges become a standard scanner target.

The KEV listing matters for one practical reason: it is evidence, not hypothesis. A CVE on the Known Exploited Vulnerabilities catalog means CISA has confirmed someone is exploiting it in the wild, which turns a patch decision from “when convenient” into “this week”. For a self-hosted forge with no vendor to lean on, that signal is the difference between acting and being found — and, as the Habr incident shows, being found takes about eleven seconds.

The order of operations

The fix is not a single patch. Order matters, because the flaw may already have been exploited before you noticed:

• Upgrade to Gitea 1.27.2, the latest release (1.27.1 already fixes the flaw; 1.27.2 is recommended).
• Disable open registration, or at minimum require email confirmation and a CAPTCHA, and remove superfluous signup methods.
• Run a compromise inventory: an upgrade does not evict access already obtained. Look for unexpected hooks, recent accounts and anomalous branches.
• Rotate all secrets: database passwords, OAuth tokens, integration keys, and anything the OS user could read.
• Tighten isolation: restrict outbound network access from the container, and never expose the forge directly without a reverse proxy and filtering.

Managed forge versus self-hosted forge

The choice to self-host is not just about cost; it is about who carries patch responsibility. A managed forge ships fixes within hours of a disclosure; a self-hosted forge waits for its administrator. In the case of CVE-2026-60004, the flaw was fixed in Gitea 1.27.1 in late July, but the documented exploitation hit an instance still on an older version — that month-long gap is the real risk factor.

The gap widens further on exposure. Where a managed offering enforces a controlled account model, a self-hosted forge often leaves open registration enabled. That setting, more than the flaw itself, turned an automated scan into a compromise: without it, the attacker would have needed a legitimate account.

That the payload was a miner rather than an exfiltrator is itself a signal: the automated attacker monetizes immediately, without targeting any specific repository. It is the signature of a mass market, where every exposed instance is eventually found — which makes the patch all the more urgent. The marginal cost of one more scan is near zero, so the only real defense is to stop being an easy target.

After upgrading, auditing hooks is worth scripting, because a malicious hook already installed survives the patch:

# List non-sample repository hooks (an unexpected hook = retained access)
find /var/lib/gitea/git/repositories -path '*/hooks/*' -type f \
  ! -name '*.sample' -exec ls -l {} \; 2>/dev/null

The lesson is one sentence: self-hosting does not excuse you from administering. A forge is a security product like any other — with patches to track, secrets to rotate and a surface to shrink.

Verdict

If you self-host Gitea, patch to 1.27.2 today — the CISA federal deadline is August 28, and an automated scanner will not wait. The upgrade is the minimum step; the real decision is to close open registration, because that is what turns a repository bug into a network door.

If you expose a forge to outside contributors, do not run bare self-hosting: place it behind external authentication (SSO), and accept that a public repository on an open-registration instance is a surface you no longer control. The cost of an 11-second crypto-miner is low; the cost of a silent repository exfiltration is not.

References

• Critical Gitea vulnerability now exploited in the wild (CVE-2026-60004) — Help Net Security, August 26, 2026
• Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload — The Hacker News, August 26, 2026
• CISA Adds One Known Exploited Vulnerability to Catalog — CISA, August 25, 2026