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. The bug 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, which is the standard industry rating for how bad a flaw is on a scale of 0 to 10. Anything above 9.0 is considered critical.
In plain terms: a person who is allowed to submit code changes to a project can trick Gitea into treating attacker-controlled patch content as a Git hook, which is a small script Git runs automatically at certain moments. Once planted, that script executes shell commands, the same kind of instructions a system administrator would type at a terminal, 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. If you administer a Gitea server, the practical answer is to update to 1.27.1 or later 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 to a repository submits a specially crafted patch. Gitea handles that patch in a way that lets the attacker place a file into the repository's Git hooks directory. Git hooks are scripts Git runs at defined points, such as when someone pushes a commit. Once the file is there, the next triggering action runs the attacker's commands on the server.
Because the commands run as the Gitea service account, the attacker inherits whatever that account can read, write or reach on the network. On many self-hosted setups, that account has access to the code of every project on the instance and to the database that backs it.
Who is at risk?
Self-hosted Gitea operators, meaning organisations that run the software on their own machines rather than paying a cloud provider. The typical exposure is an internal engineering team's code server, sometimes reachable only inside the corporate network, sometimes exposed to the wider internet.
A fully external attacker cannot fire this off cold. They need an account with write access to at least one repository. Where that matters most is on instances that accept outside contributors, or where a low-privilege internal account gets stolen through a phishing email and then reused to escalate.
What should administrators do now?
Update to Gitea 1.27.1. Check who has write access on your instance and remove accounts that no longer need it. Review server logs for unexpected files appearing in any repository's hooks directory, and for shell processes spawned by the Gitea service account outside normal working hours.
If you cannot patch immediately, restricting who can push to repositories reduces the pool of accounts that could trigger the bug, though it does not close the hole.
