SURIQ
The dangerous stretch for anyone self-hosting Gitea was not the day the patch shipped. It was the twenty-eight days after. Gitea released version 1.27.1 on July 28, and a working proof-of-concept exploit went public the same day, published in the advisory and credited to the researcher NightRang3r. CISA only added the bug, CVE-2026-60004, to its Known Exploited Vulnerabilities catalog on August 25, with a federal deadline of August 28. That month-long gap, patch available and exploit public well before exploitation was confirmed, is the part that should worry you more than the flaw itself.
If you run Gitea and have not touched it since July, the question has quietly shifted from are we patched to were we already hit. Here is what the flaw does, who is actually exposed, and the one on-host signal that tells you whether someone walked through the window before you closed it.
What the flaw does
Gitea is a lightweight, self-hosted Git service that many teams run in place of GitHub for private code. The bug lives in its patch-apply feature, the diffpatch API endpoint. A crafted patch, through a collision in how Git applies changes inside a bare repository, writes an executable file into the repository's hooks directory. Git then runs that file as a hook the next time it updates the index, and the commands execute as the operating-system account Gitea runs under. Gitea rates it 9.8 out of 10 and classifies it as code injection (CWE-94). The official advisory credits the researcher known as NightRang3r and gives the affected range plainly: every release from 1.17 up to but not including 1.27.1.
The published proof of concept does one thing worth flagging for defenders. It does not phone home. Rather than an outbound callback, it stashes command output inside Git objects and pulls it back over ordinary authenticated Git-over-HTTP traffic, as CyCognito noted in its writeup. That design choice changes how you detect it, which I will come back to.
Why "needs write access" understates it
Read the CVSS vector and one field looks reassuring: privileges required, none. Read the advisory and you see why. The exploit needs plain write access to some repository. On paper that sounds like it only touches teams who hand out repo permissions. In practice, Gitea enables open registration by default. On a default install, anyone passing by can sign up, spin up a repository of their own, and immediately hold the write access this exploit depends on. The "privileges: none" rating is literal on any Gitea that still accepts signups.
So the exposed population is not "orgs that grant write access." It is every internet-reachable Gitea with registration left on, which is the out-of-the-box state. That is a much larger group than the CVSS text implies, and it is a good part of why this reached the exploited list quickly.
The window, in dates
The fix and a working exploit both went public on July 28. CISA confirmed real-world exploitation and added the flaw on August 25, twenty-eight days later, then set the federal patch deadline three days out on August 28. That three-day figure is worth a second look. CISA's usual KEV deadline runs closer to three weeks. A window this compressed suggests the agency is seeing exploitation serious or widespread enough to treat as urgent rather than a routine catalog add.
Patching closes the door. It does not tell you who already came in.
Upgrading to 1.27.1 stops future exploitation. It says nothing about whether someone used the exploit during the month it sat public. For that you look at artifacts on the host, and this flaw leaves two good ones.
First, the whole trick is planting an executable Git hook where none belongs. A file such as post-index-change turning up under the hooks directory of a bare repository, especially one with recent write activity, is the smoking gun. File-integrity monitoring on your repository storage, watching for new or newly-executable files in hooks paths, catches it whether or not you have patched.
Second, watch process lineage. Gitea's service account has no reason to spawn sh, bash, or an interpreter as a child of the Gitea process during a routine index update. That parent-child pattern is the execution itself, and it is hard for an attacker to avoid. Because the public exploit exfiltrates over authenticated Git-over-HTTP rather than a callback, do not lean on egress monitoring here: watching outbound connections from the Gitea host will miss it. The durable signal is on the host, not on the wire.
What to do this week
-
Patch to Gitea 1.27.1 or later. This is the only real fix. Everything below buys time, not safety.
-
If you cannot patch today, mount the temporary directory Gitea uses as
noexec. The exploit needs a writable and executable temp filesystem to stage its hook, so anoexecmount is the most durable stopgap. -
Turn off open registration on any internet-facing instance. This shrinks who can reach the flaw, but be honest about the limit: it does nothing about accounts already created, and it is not a fix. The advisory says as much.
-
Block the
diffpatchroute at your reverse proxy or web application firewall until the upgrade is done. -
Hunt backward. Check
hooksdirectories for unexpected executables and review process history for the Gitea account spawning a shell since late July.
The pattern worth remembering
Self-hosted developer tools keep producing this exact shape of bug: a feature that turns repository content into code execution, reachable by anyone who can sign up. We saw it when Gitea's Docker image trusted a reverse-proxy login header, in self-hosted Gogs leaking repositories through its mirror settings, in a no-login session hijack in self-hosted GitLab, and in Adminer's authenticated path to code execution. Running your own Git server is a fair call, but it puts the patch clock on your team, and CVE-2026-60004 shows how short that clock can run. Treat the diffpatch bug as today's work, then decide whether a stranger should be able to register on your code server at all.