CVE-2026-60004 turns a code-review-adjacent API into a path for executing operating-system commands on a Gitea server. Gitea is the open-source, self-hosted Git service that teams use for repositories, pull requests, issues, packages and CI/CD; think of it as infrastructure in the same role as a self-hosted GitHub, GitLab or Bitbucket. It runs everywhere from a small team’s inexpensive internal server to development environments at larger firms, schools and organisations that keep source code under their own control.
The affected range is Gitea 1.17 and later before 1.27.1. The attacker needs repository write access, but that does not necessarily mean they begin as an established insider: on instances with open registration, they can register, create a repository and obtain the needed position themselves. Closing registration removes that route, not the risk posed by existing writers.
A patch becomes a live Git hook
The vulnerable diffpatch endpoint applies a repository-controlled patch inside a temporary bare Git clone. Sending the same crafted patch twice creates an add/add collision, causing Git to use a three-way fallback and check out an indexed path despite the --cached handling. In a bare clone, the repository root is also Git’s metadata directory, $GIT_DIR.
That distinction is the exploit: a patch can create an executable hooks/post-index-change file exactly where Git treats it as a hook. When Git subsequently writes the index, it invokes the hook and the attacker’s shell commands run as the Gitea operating-system account. The vendor advisory says exploitation also depends on Git 2.32 or newer, an enabled diffpatch route, and writable, executable temporary storage.
The relevant fix is deceptively small: Gitea now uses a non-bare temporary clone, keeping working-tree files out of $GIT_DIR.
// here must NOT use bare repo, because the following git commands might operate working tree ("--index") directly
if err := t.Clone(ctx, opts.OldBranch, false); err != nil {
return nil, err
}What matters is false: a hook planted through patch content no longer lands in the active hooks directory. The 1.27.1 release describes the security item tersely as a fix for Git patch application.
Exploitation makes internet-facing instances urgent
This is not a theoretical edge case. CVE-2026-60004 is confirmed exploited in the wild and CISA added it to the Known Exploited Vulnerabilities catalogue on August 25, 2026, setting an August 28 federal remediation deadline. Public reporting describes an exposed web studio instance with open registration where an attacker registered, created a private repository, issued two diffpatch requests and retrieved id output as the container’s git user; the reported follow-on downloader was described as miner-like, but its final payload, operator and any link to CISA’s evidence remain unconfirmed.
There is also no shortage of reproduction material: the vendor advisory includes a Python proof of concept, and a separate public exploit implementation is available. Teams should treat public-facing Gitea as a priority: upgrade to 1.27.1 or a later fixed 1.27 release, review who can write repositories, disable open registration where it is not needed, and hunt service-account activity and temporary-repository artifacts around diffpatch use. Registration controls are worthwhile friction, but they are not a substitute for patching.
For environments that run Gitea, this is a reminder that repository permissions can become host-level permissions when server-side Git plumbing is involved. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, helping teams find those exposed instances before a KEV entry forces the issue.
