Code injection in Gitea (CVE-2026-60004) — planting a Git hook that runs as the service account

1Git hooks as an execution mechanism

Git has a mechanism called hooks: scripts that run automatically when a defined event occurs — before or after a commit, on receiving a push. They exist to automate format checks, notifications, and build triggers. Turned around, though, it means that placing an executable file where hooks live causes code to run the moment that event happens. What an attacker targets is exactly that property: put it there and it runs.

2Running "as the service account"

The catalog states plainly that execution happens as the Gitea service account. That account holds rights over the files of every hosted repository and over Gitea's own configuration and database. So an attacker holding write access to one repository can move from there to privileges over the whole server.

Handing someone write access to a single repository must not amount to handing over the server — and that boundary is broken.

3Development infrastructure as a target

Gitea is chosen where an organization wants to manage source code itself rather than through a cloud service. Source code, build configuration, and often deployment credentials gather there. When development infrastructure is breached, the effect does not stay on that server; it can spread into whatever is distributed from it.

This site separately holds a flaw in an artifact repository (JFrog Artifactory), so products sitting in the development supply chain can be seen landing in KEV in succession.

4The property that placing it makes it run

A Git hook is a script that runs automatically when a defined event occurs. It exists for automation, and that property is exactly what the attack uses.

1. 1Write into the hook directoryWrite access to one repository is enough
2. 2A defined event occursBefore or after a commit, on receiving a push
3. 3The script runs automaticallyThe property that placing it makes it run is used as it is
4. 4It runs as the service accountThat account reaches every repository's files and Gitea's own configuration and database

An attacker holding only write access to one repository can move from there to privilege over the whole server. Handing over privilege on one repository must not amount to handing over privilege on the server — and that boundary is broken. Write access to a repository is distributed fairly widely inside an organisation, which changes how the weight of the precondition should be judged.