Gitea CVE-2026-60004 is being exploited and the patch deadline is tomorrow
Key takeaways
- CVE-2026-60004 is a CVSS 9.8 code injection in Gitea's diffpatch API endpoint, letting an attacker run shell commands as the Gitea service account
- Every version from 1.17 onward is affected. Gitea 1.27.1 contains the fix
- CISA added it to the KEV catalogue on 25 August with a 28 August deadline for US federal civilian agencies
- Exploitation needs repository write access, which is a much lower bar on a self-hosted instance with old contributors still on the list
CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) catalogue on 25 August and gave US federal civilian agencies until 28 August to fix it. That is tomorrow. If you run a self-hosted Gitea instance, you do not have a federal deadline, but you do have the same flaw.
According to CISA, The Hacker News and Help Net Security, the bug is being exploited in the wild. The fix is Gitea 1.27.1, and the rest of this piece explains what the flaw does, who is exposed and what to check today.
What does CVE-2026-60004 in Gitea actually do?
It is a code injection in Gitea's diffpatch API endpoint, scored CVSS 9.8. CVSS is the standard 0 to 10 severity scale, so 9.8 sits at the very top of the critical band. Code injection means the application takes input an attacker controls and ends up treating part of it as instructions to run.
The attack chain is short. An attacker with ordinary write access to a repository sends a crafted patch, plants an executable Git hook, and from there runs shell commands as the Gitea service account. A Git hook is a script that Git runs automatically at set moments, such as before a commit, which makes it a convenient place to hide code that keeps running.
Every version from 1.17 onward is affected. Version 1.27.1 fixes it.
How worried should you be?
Note the shape of this one, because it changes the answer. This is not an unauthenticated worm crawling the internet. It needs repository write access. On a corporate instance with tight access control that is a real barrier.
On a self-hosted box it is much lower than it sounds. Think of a contributor you gave commit rights to two years ago, a client, or a former colleague whose account nobody removed. Each of those is a valid starting point for this attack.
At least one reported attack ended with a dropper behaving like a crypto miner. A dropper is a small piece of software whose only job is to fetch and start something larger. Mining is the noisy, obvious outcome, and an attacker running as the Gitea service account could just as easily read source code or stored credentials quietly.
Why does write access matter so much here?
Git hosting exists to let people push code, so write access is the most ordinary permission on the platform. Nobody thinks of a commit right as a shell login, but this bug turns it into one. The patch is the delivery mechanism and the hook is what makes the access stick.
That is also why the attack is hard to spot in logs. A crafted patch submitted through the API looks like routine repository traffic, and a hook only runs when Git triggers it. Reviewing who can write, and what is sitting in each hooks folder, is more reliable than waiting for an alert.
Is your instance affected? A quick reference
| Question | What to check | What it means |
|---|---|---|
| Which version are you on? | gitea --version or the footer of the web UI | 1.17 or newer and below 1.27.1 is affected |
| Who has write access? | Collaborator and team lists on every repository | Anyone you would not give a shell to is a live path |
| Are there unexpected hooks? | .git/hooks in each repository | A hook you did not add is a sign of compromise |
| Is it fixed? | Gitea 1.27.1 installed and running | The diffpatch flaw is closed |
The three question check
Run these now, in order.
- Are you on Gitea 1.17 or newer and below 1.27.1? If yes, you are affected. Check with
gitea --versionor the footer of your instance's web UI. - Who currently has write access to any repository on that instance? Not who should have it. Who has it. Anyone on that list you would not hand a shell to is a live path to this bug.
- Have you checked
.git/hookson your repositories for anything you did not put there? A planted hook is the persistence mechanism, so a patch alone does not clean up an instance that was already hit.
Upgrading to 1.27.1 closes the door. Auditing your collaborator list and hooks tells you whether anyone came through it first.
If you find a hook you cannot explain, treat the server as compromised. Remove the hook, but also rotate any secrets the Gitea service account could read, such as deploy keys and tokens stored for webhooks, because a shell as that account can read them.
Gitea's own releases are the place to confirm the fix, and the reporting from CISA, The Hacker News and Help Net Security all points to 1.27.1 as the patched version. If you cannot upgrade today, restricting write access to the smallest possible group is the only sensible stopgap, and it is worth doing anyway.
Why do self-hosters keep getting caught by this pattern?
Self-hosted Git is the default now for anyone who wants their code off someone else's server, and that is a reasonable choice. It just moves the patching burden onto you, permanently. A CVSS 9.8 with a three day federal deadline is exactly the kind of thing a one-person instance misses, because there is no security team sending the email.
The tight deadline is not unusual any more. We covered why CISA now expects fixes so quickly in the three day patch window, and the same logic applies to anyone who exposes a code host to other people.
August has been busy on this front. CISA's August 2026 KEV additions already included a 9.8 macOS Screen Sharing bypass and a 9.1 in SharePoint. Before that came the Keycloak flaw CVE-2026-18963, and a separate GitLab vulnerability scored a perfect 10 that attackers noticed quickly. The common thread is not that self-hosted software is worse. It is that the update does not install itself.
What should you do this month?
If you run anything on your own hardware, the practical fix is not vigilance, which fails, but a calendar entry. Once a month, check versions on everything you host and read the KEV catalogue. Our guide on how to check the CISA KEV catalogue walks through it.
It takes twenty minutes and it is the difference between patching on the deadline and finding out from your electricity bill.
For Gitea specifically, the order is simple. Upgrade to 1.27.1 first, because that is the only change that removes the flaw itself. Then prune the collaborator list down to people who still need access, and look through your hooks, including those on archived and forked repositories that nobody has opened in months. Do those three things and you have dealt with both the bug and the most likely way it would have been used against you.
Key takeaways
- CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalogue on 25 August.
- US federal civilian agencies have until 28 August to fix the vulnerability.
- CVE-2026-60004 is a code injection in Gitea's diffpatch API endpoint, scored CVSS 9.8.
- Every Gitea version from 1.17 onward is affected, with version 1.27.1 fixing the issue.
- Self-hosted Gitea instances are also vulnerable, but do not have a federal deadline to fix the issue.
