TL;DR — The Gitea RCE tracked as CVE-2026-60004 turns a patch-preview feature into arbitrary shell execution. On a default install, an attacker registers an account, creates a repository, and plants a Git hook that Git then runs for them. Every version from 1.17 is affected; the fix is 1.27.1. CISA confirmed exploitation yesterday, and it was not listed as a security item in the release notes.
What Is the Gitea RCE?
Gitea is a lightweight, self-hosted Git service — repository hosting, code review, issue tracking and CI/CD, popular with teams who want GitHub’s shape without GitHub’s hosting. Like any source-control platform, it holds the code, the pipelines, and the credentials those pipelines use.
The Gitea RCE lives in the diffpatch API endpoint, which applies a submitted patch so the result can be previewed. An attacker with write access to any repository can use it to place an executable file where Git expects to find a hook, and Git then runs it — executing shell commands as the Gitea service account.
The write-access requirement sounds like a real barrier, and on a hardened deployment it is. Gitea’s defaults are not hardened. Out of the box it leaves registration open, requires neither email confirmation nor administrator approval, does not restrict new accounts, and sets no repository-creation limit. On an unmodified install, an anonymous visitor signs up, creates a repository, and has everything the exploit needs. That is why the CVSS vector records privileges required as none.
Affected versions run from 1.17 up to but not including 1.27.1 — a range spanning several years of releases. Gitea Cloud instances were upgraded automatically.
How the Gitea RCE Works
This one is a small masterpiece of unintended consequences, and worth walking through because every step is a component behaving correctly.
When a patch is submitted, Gitea applies it inside a shared bare temporary clone. In a bare repository there is no working tree, so the repository root is the Git directory — the place where hooks/, config and the object store live. A patch that writes to the path hooks/post-index-change therefore writes directly into Git’s active hook directory.
Submitting the same patch twice produces an add/add collision, which is the mechanism that gets the file created. Because the patch marks it executable, Git treats it as a live hook and runs it while updating the index. The attacker’s shell commands execute with the privileges of the operating system account running Gitea.
Nothing here is a memory bug or a parsing failure. A bare clone put the hook directory inside the writable area, and every component downstream did exactly what it was documented to do.
The classification is CWE-94, code injection. Notably it does not grant root — commands run as the Gitea service account. Whether that matters depends entirely on your isolation. Gitea’s own advisory lists what a poorly isolated service account exposes: app.ini and application secrets, process environment variables, mounted repositories, database credentials and contents, OAuth and integration credentials, and whatever internal services the host can reach.
Reading the CVSS Score
9.8, and the metric worth arguing about is the one that gets it there.
PR:N — privileges required, none — is doing a lot of work, and it is a judgement about defaults rather than about the code. The exploit genuinely needs repository write access. The vector scores it as requiring nothing because obtaining that access on a stock install is a registration form away.
That is the correct call, and it is a useful reminder that severity is a property of deployments as much as of code. If your Gitea instance requires administrator approval for new accounts, your real exposure is closer to a privileged-user problem than a 9.8. If it does not, the score is accurate. Same CVE, materially different risk, decided by a configuration toggle.
Active Exploitation of the Gitea RCE
Gitea released 1.27.1 on 27 July 2026 and published the advisory the following day, crediting researcher Shai Rod (NightRang3r). The advisory did not report exploitation at the time — but it did include proof-of-concept code.
The exploitation evidence that has surfaced is unusually granular, and it came from a victim rather than a vendor. A developer publishing on Habr described their Gitea instance being hit with what they characterised as a cryptocurrency-miner-like dropper. They found out because their hosting provider emailed to say the virtual server had been sustaining over 70% CPU for an extended period, in breach of the terms of service, and had been throttled as a result.
CISA added the CVE to KEV on 25 August with a remediation deadline of 28 August. No attribution has been published and the scale is unclear — a single detailed public account plus CISA confirmation is what exists. That is thinner evidence than the vCenter or Metabase campaigns, and worth stating plainly rather than implying a wave.
One detail that deserves attention on its own. The fix appeared in the 1.27.1 release notes under the MISC section as a refactor of Git patch application, not as a flagged security item. Anyone triaging that release by scanning for security entries would have read past it. What to hunt for:
- Files in the
hooks/directory of any repository that nobody configured — particularlypost-index-change, which has few legitimate uses - Requests to
/api/v1/repos/{owner}/{repo}/diffpatch, especially repeated identical submissions from the same account - Newly registered accounts that immediately create a repository and go quiet — the signature of an account created solely to obtain write access
- Sustained high CPU on the Gitea host with no matching build activity, and outbound connections to mining pools or unexplained destinations
- Child processes spawned by the Gitea service account, and any access to
app.inioutside normal service startup
Remediation & Mitigation: Patching Gitea
Upgrade to Gitea 1.27.1 or later. It has been available since 27 July. Gitea Cloud instances were updated by the vendor.
- Patch first. Every self-hosted instance from 1.17 onwards, including the one running a team’s side projects that nobody formally owns.
- Close open registration if you have not already. Requiring administrator approval or email confirmation removes the anonymous path to write access — though note this is hardening, not a fix: any existing or compromised account can still exploit an unpatched instance.
- Check the hooks directories. Patching does not remove a hook already planted. This is the step most likely to be skipped and the one most likely to matter.
- Rotate what the service account could read. Database credentials, OAuth and integration tokens, anything in
app.ini. Assume it was readable. - Review recent build outputs. Code execution on a Git host with CI/CD attached is a supply-chain problem, not just a server problem.
- Constrain the service account. The blast radius here is defined entirely by what that account can reach — run Gitea with minimal privileges and real isolation.
Two lessons worth carrying beyond Gitea. The first is about defaults as security decisions. Open registration is a reasonable choice for a public code-hosting service and a poor one for an internal instance, and the difference between those two deployments is the difference between a 9.8 and a much smaller problem. Ship-time defaults become the security posture of everyone who never changes them.
The second is about changelogs. A security fix filed as a refactor is invisible to anyone who prioritises upgrades by reading release notes — which is most teams. If your patching decisions depend on a vendor labelling something as security-relevant, you are dependent on their labelling being complete.
Related ZeroDayHub Coverage
Developer infrastructure keeps proving to be high-value: the TeamCity unauthenticated RCE, where the build server’s stored credentials were the prize, and the earlier Gitea Docker authentication bypass, which remains uncatalogued by CISA.
Sources & Further Reading
- CISA Known Exploited Vulnerabilities Catalog
- NVD — CVE-2026-60004
- Gitea — Security advisory GHSA-rcr6-4jqh-j84m
- The Hacker News — Exploitation and the reported dropper
- SecurityWeek — CISA warning and KEV deadline
- CyCognito — Root cause and default-configuration analysis
- runZero — Finding affected assets
Leave a Reply