2026-08-30 · view entry permalink →
CVE-2026-60004: Gitea's diffpatch endpoint turns an attacker-supplied patch into a live Git hook, giving command execution as the service account; KEV-listed after miner deployment
CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog on 2026-08-25. The flaw is in services/repository/files/patch.go, the code behind Gitea's diffpatch endpoint, which applies an attacker-controlled patch inside a shared bare temporary clone. The maintainers describe the chain precisely: "submitting the same patch twice creates an add/add collision. Git's three-way fallback checks the indexed path out even though the operation is performed with --cached" (Gitea maintainers, 2026-07-28). In a bare clone the repository root is $GIT_DIR, so a checked-out executable entry whose path matches a Git hook name is not a file sitting next to the hooks directory, it is a hook. Git then invokes it while writing the index, and it runs as the Gitea OS account.
The precondition is the part worth reading twice. The advisory states it plainly: "an attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user. With default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository" (same advisory). Ordinary write access is not a privileged role, it is what every user of a Git forge has by definition, and Gitea's shipped default hands it to anyone who can reach the login page. So on a default-configured instance this is a pre-authentication flaw in every sense that matters operationally, separated from an anonymous visitor only by a registration form. Fixed in Gitea 1.27.1. The advisory carries a working proof-of-concept, which arrived with it.
Exploitation is opportunistic and automated. Help Net Security reports the incident write-up of an operator whose self-hosted instance was compromised: "because the server ran an outdated version of Gitea, with open user registration and no email confirmation or CAPTCHA, an automated scanner was able to register an account, create its own repository, and trigger the exploit chain" (Help Net Security, 2026-08-26). The chain wrote a proof of execution into a Git branch, then pulled a shell loader followed by a miner; the operator was alerted not by security tooling but by the hosting provider flagging sustained CPU. That is a mass-scanning profile against a default configuration, not targeted intrusion, and it means exposure is a function of being reachable rather than being interesting.
The blast radius is broader than the payload suggests. Depending on container isolation and the privileges of the Gitea OS user, exploitation can expose the main configuration file, application and process-environment secrets, database credentials and contents, and OAuth and integration credentials (same reporting). A miner is the noisy outcome; the quiet one is a set of credentials into whatever the forge is wired to, which for a public-sector development estate typically means CI runners, artefact registries and identity providers.
Where the activity surfaces. The exploitation itself looks like ordinary API traffic, so the durable signal is what the service account does immediately afterwards. Watch for the Gitea service account spawning a shell or an interpreter within seconds of a patch or diff API call, on a host whose normal process tree is a Go binary plus git. On the repository side, the artefact is a Git hook whose content arrived through patch application rather than through an administrator action, so an executable object at a hook path in a repository nobody manages is the thing to hunt for. Registration and repository-creation events are the leading indicator: on an instance with real users, a self-registered account creating a single repository and immediately exercising the diff endpoints is not a normal usage pattern.
Triage: the benign lookalike is a legitimate developer using diffpatch to apply a patch, which is what the endpoint is for and which will be the overwhelming majority of hits on that route. Two things separate exploitation from it. First, the same patch applied twice in quick succession, which is the collision the attack requires and which a human working normally has no reason to produce. Second, and more reliably, what happens next: a legitimate patch application ends with a commit, while this one ends with the service account executing something. Alert on the process behaviour, use the endpoint traffic to explain it.
An attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user. With default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository.
Submitting the same patch twice creates an add/add collision. Git's three-way fallback checks the indexed path out even though the operation is performed with --cached.
Because the server ran an outdated version of Gitea, with open user registration and no email confirmation or CAPTCHA, an automated scanner was able to register an account, create its own repository, and trigger the exploit chain.
Red Heron scanned 1,386 Gitea instances across seven countries and maintained a separate dataset of 477 Taiwan-based systems. Targets were classified using Simplified Chinese labels covering defense, elections, energy, aerospace, telecommunications, government, and research. Confirmed compromises affected organizations in Canada, Argentina, Taiwan, the United States, and Sri Lanka.
The staging server also contained JITTERLY, a C++ Linux implant supporting more than 30 post-exploitation commands, including shell execution, file transfer, network tunneling, interactive terminal access, and internal pivoting. Embedded inside it was SIXZUT, a previously undocumented LD_PRELOAD rootkit capable of hiding files, processes, and network connections, preventing the implant from being terminated, and relaunching it if the process is stopped while the binary remains present.
Acronis Threat Research Unit documents a second, targeted exploitation of this same vulnerability, distinct from the opportunistic cryptomining incident above: a Chinese-speaking actor it tracks as Red Heron, assessed with moderate confidence to operate in a PRC-linked context, turned public proof-of-concept code into an automated exploitation framework within days of the July 2026 advisory (Acronis Threat Research Unit, 2026-09-13). The actor scanned 1,386 Gitea instances across seven countries and maintained a separate target list of 477 Taiwan-based systems, classifying candidates by sector (defense, elections, energy, aerospace, telecommunications, government and research) and confirmed compromises in Canada, Argentina, Taiwan, the United States and Sri Lanka, including source-code theft, credential collection, SSH-key persistence and lateral movement (Acronis Threat Research Unit, 2026-09-13). In one Taiwanese environment the actor escalated from the Gitea compromise to an obtained Proxmox root authentication ticket, reaching root-level administrative access across a three-node Proxmox cluster and initiating full virtual-machine backup operations that would have exfiltrated complete VM disk images had they completed.
Acronis traced a Linux implant, which it tracks as JITTERLY, to Red Heron's own exposed staging server. JITTERLY is a C++ implant compatible with the Adaptix C2 framework's protocol, communicating over raw TCP with msgpack-serialized, AES-128-GCM-encrypted messages, and supporting more than 30 post-exploitation commands including SOCKS/TCP tunneling, reverse port forwarding, internal pivot relaying and an interactive terminal (Acronis Threat Research Unit, 2026-09-13). Embedded inside JITTERLY as an encrypted blob is a previously undocumented LD_PRELOAD rootkit Acronis tracks as SIXZUT, which hooks libc file, directory, socket and signal-handling functions to hide its own files, hide matching processes from /proc listings, hide matching network connections from /proc/net/* reads and netlink socket queries alike, and re-launch the implant if it is killed while the rootkit's own library remains loaded via /etc/ld.so.preload (Acronis Threat Research Unit, 2026-09-13).
Detection (Red Heron / JITTERLY / SIXZUT specific): an unexplained entry or modification to /etc/ld.so.preload is a strong signal on any Linux host, since this file is normally absent or static; because SIXZUT hides its own artifacts from userland tools, check /etc/ld.so.preload, running-process lists and /proc/net/* contents from a known-good offline image, a different host, or kernel-level/EDR telemetry rather than ls, ps, netstat or ss run on the live host itself. A kill -9 against a hidden PID that returns with no error but leaves the process running is consistent with SIXZUT's signal-hiding hook. On any Gitea instance that also fronts a Proxmox or similar virtualization API, treat a Gitea-stored credential or token reaching that management API as a lateral-movement path, not just a data-exfiltration one.
Defender takeaway (update): the same patch and registration hardening above close both the opportunistic and the targeted exploitation paths; an instance that was internet-reachable and unpatched should now also be checked for the Red Heron / JITTERLY / SIXZUT artifacts above, not only for a cryptominer, since this actor's confirmed objective on comparable targets was credential theft and persistent access rather than resource abuse.