On 25 August CISA added CVE-2026-60004 to its catalogue of confirmed exploited flaws, with a patch deadline of 28 August. The latest Gitea release is from 14 August, older than the entry itself.
- An attacker with write access sends a malicious patch and plants an executable Git hook.
- The hole does not open from the street, but the code repository is where everything else starts.
- No patch has shipped. Until it does, the work is on access, not on version numbers.
Gitea is quiet software. It sits to one side, keeps the code, and nobody thinks about it while it works.
Since 25 August it is not quiet.
What makes this one awkward
The usual advice for a story like this is one word: update. Here there is nothing to update to.
The condition for the attack is write access, so the hole does not open from the street. It wants an account or a token that can already write to a repository. From there, though, everything follows: the hook runs from Git itself on the next push and carries whatever was written into it, without asking.
What you do while there is no patch
You look at access. Who has write rights and still needs them, which tokens are alive, when they were last used, and which ones go today.
Then you check whether a hook is already sitting there: walk the hooks directory of the repositories and look at what is inside and how long it has been there.
And you narrow who reaches the port at all. An internal git listening on every interface is wide out of habit, not out of need.
We are writing this from our own side of the table too. We run Gitea, ours is internal with no path from the internet, and that removes half the weight; the other half is work for the week.
You update the day it ships; until then you tighten the circle.