A patch window that closes today
Gitea is open-source software that teams install on their own servers to host Git repositories, the same basic job GitHub or GitLab does, but self-managed. On August 25, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added a critical Gitea flaw, tracked as CVE-2026-60004 (Common Vulnerabilities and Exposures), to its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies were given three days to patch or mitigate. That window closes today, August 28.
The bug scores 9.8 out of 10 on the Common Vulnerability Scoring System (CVSS), and it is not a theoretical risk: it is already being used in live attacks against self-hosted servers.
How the exploit works
CVE-2026-60004 lives in Gitea's diffpatch API endpoint, the code path that handles patches submitted against a repository. It is classified as CWE-94, improper control of code generation, which is a fancy way of saying it lets an attacker get their own code to run.
An attacker with write access to a repository can submit a crafted, conflicting patch to that endpoint. Git's three-way merge logic, which normally reconciles two sets of conflicting changes, ends up writing an attacker-supplied file into a spot Git treats as a hook, a script it runs automatically after certain repository operations change the index. Once that file is in place, Gitea triggers it without any further action from anyone, and the attacker's commands run under the account the Gitea service itself uses.
What turns this into an urgent problem rather than a niche one is Gitea's default configuration: open self-registration. Out of the box, anyone on the internet can create an account, spin up a repository, and walk the exploit chain from a cold start, no invitation or prior access required.
Eleven seconds from signup to shell
Security researcher Shai Rod, who publishes under the handle NightRang3r and works at Salesforce, is credited with finding the bug. Documented attacks against real instances show how quickly it can be turned into full compromise: one server was taken over roughly eleven seconds after the attacker registered an account. From there, the recorded sequence was to commit a working proof of the exploit to a branch, pull down a generic shell-loading script, and use it to install a cryptocurrency miner. On the affected host, that miner reportedly drove CPU (central processing unit) usage above 70%, competing with the server's normal workload for resources.
Because the exploit runs with the privileges of the Gitea service account, the actual blast radius depends on how a given deployment is set up. Configuration files, database credentials, and any secrets or OAuth (Open Authorization) tokens stored on the same host are realistic targets wherever the service isn't isolated from the rest of the system.
Who is exposed, and the fix
The flaw affects Gitea versions 1.17 through 1.27.0. It was fixed in 1.27.1, released July 27, 2026, by changing how the temporary clone used during patch processing is created, switching it from a bare to a non-bare repository so the hook-write path is no longer available. Version 1.27.2 is current.
Security-scanning service Shadowserver counts roughly 5,000 Gitea instances reachable from the internet. That number includes servers that are already patched and honeypots deliberately exposed to study the attack, so it is not a count of how many remain vulnerable, but it gives a sense of the scale of self-hosted Gitea's footprint.
What this means in practice
Two actions matter more than anything else if you run Gitea:
- Upgrade to 1.27.1 or later now. 1.27.2 is the current release.
- Disable open self-registration unless your instance genuinely needs to accept anonymous sign-ups. It is the piece of the chain that lets an attacker start from nothing.
CISA's deadline applies to US federal agencies, but the underlying exposure does not stop at government networks. Any team running an internet-facing Gitea instance is reachable the same way, and the eleven-second compromise recorded in the wild is not a worst-case estimate, it is what has already happened to at least one server. If a full upgrade cannot happen today, taking the instance off the open internet or turning off self-registration is a reasonable stopgap until it can.
