Gitea Patches Critical Flaw That Lets Repo Users Run Shell Commands
CVE-2026-60004 carries a 9.8 CVSS score and is fixed in Gitea 1.27.1. Anyone running an older self-hosted instance should update now.
Key points
- Gitea released version 1.27.1 to fix CVE-2026-60004, a remote code execution flaw scoring 9.8 out of 10 on the industry severity scale.
- The bug affects every Gitea release from 1.17 up to but not including 1.27.1.
- A user with ordinary write access to a repository can abuse patch content to plant a Git hook and run shell commands as the Gitea service account.
- Self-hosted Gitea administrators are the population at risk; there is no cloud vendor to patch this for them.
- No public reports of exploitation have surfaced at the time of writing, but the low bar to abuse makes prompt patching sensible.
Gitea, an open-source platform that companies and developers install on their own servers to host code, has shipped a fix for a serious security flaw. It lets a logged-in user who can write to any repository take over the server the software runs on.
The vulnerability is tracked as CVE-2026-60004 and carries a CVSS score of 9.8, the standard industry rating for severity on a scale of 0 to 10. Anything above 9.0 is critical. It's the same 9.8 threshold we saw last month with a JetBrains TeamCity flaw that also required no privilege beyond an existing account.
In plain terms: someone allowed to submit code changes to a project can trick Gitea into treating attacker-controlled patch content as a Git hook, a small script Git runs automatically at certain moments. Once planted, that script executes shell commands under the identity of the Gitea service account.
The issue was first reported by The Hacker News.
Which versions are affected?
Every Gitea release from 1.17 onward, up to but not including 1.27.1, contains the flaw. The fix ships in 1.27.1. Update immediately.
| Item | Detail |
|---|---|
| CVE ID | CVE-2026-60004 |
| CVSS score | 9.8 (critical) |
| Affected versions | 1.17 through 1.27.0 |
| Fixed version | 1.27.1 |
| Attacker requirement | Repository write access |
How does the attack work?
A user with write access submits a specially crafted patch. Gitea handles it in a way that lets the attacker place a file into the repository's Git hooks directory. The next triggering action, such as a commit push, runs the attacker's commands on the server.
Because those commands run as the Gitea service account, the attacker inherits whatever that account can read or reach on the network. On many self-hosted setups, that's the code of every project on the instance and the backing database.
Who is at risk?
Self-hosted Gitea operators: organisations running the software on their own machines rather than through a cloud provider. The typical exposure is an internal engineering team's code server, sometimes inside the corporate network, sometimes on the open internet.
A fully external attacker can't fire this off cold. They need an account with write access to at least one repository. That matters most on instances that accept outside contributors, or where a low-privilege internal account is stolen through phishing and then reused to escalate.
What should administrators do now?
Update to Gitea 1.27.1. Check who holds write access on your instance and remove accounts that no longer need it. Review server logs for unexpected files in any repository's hooks directory, and for shell processes spawned by the Gitea service account outside normal working hours.
If patching isn't immediately possible, restricting push access shrinks the pool of accounts that could trigger the bug. It doesn't close the hole.
The pattern worth watching here isn't the vulnerability itself but what surrounds it: self-hosted developer tooling keeps producing critical flaws that cloud customers never have to think about. Gitea's operators are on their own, and with a 9.8-rated bug requiring nothing beyond a routine contributor account, the window between disclosure and attempted exploitation tends to be short.
