FR
live
Security Critical

Red Heron turns the Gitea flaw into an industrial espionage campaign and drops a novel Linux rootkit

A Chinese-speaking actor tracked as Red Heron exploited CVE-2026-60004, the Gitea RCE, to scan 1,386 instances across seven countries and steal industrial source code. Patch self-hosted forges, lock down registration, and treat any exposed instance as already breached.

A wall of identical dark steel filing cabinets, one drawer left open with folders faintly lit amber from within.

September 15, 2026. Acronis Threat Research Unit publishes a full account of a campaign it attributes, with moderate confidence, to a Chinese-speaking actor named Red Heron. CVE-2026-60004. The Gitea flaw patched in late July and already mass-exploited becomes the entry point for a targeted espionage operation. 1,386 instances scanned, 11 confirmed victims across 5 countries. Why it matters: a public exploit takes only days to become a structured industrial source-code theft campaign — and the self-hosted forge is where it starts.

From an opportunistic miner to a state actor

The CVE-2026-60004 flaw is not new to this blog: we covered it in August, when an automated scanner was using it to drop a cryptominer in 11 seconds on misconfigured instances. The flaw sits in Gitea’s diffpatch endpoint: an attacker with ordinary write access to a repository can install and then trigger a controlled Git hook, executing arbitrary shell commands as the forge’s system user. With open registration, the flaw effectively becomes pre-authentication.

What Red Heron shows is the jump to industrial scale. The actor built an automated exploitation framework that registers accounts, compromises vulnerable Gitea servers, steals repositories, and removes chosen traces. The campaign scanned 1,386 instances across 7 countries and maintained a separate database of 477 Taiwan-based systems, with targets classified by sector: defense, elections, energy, aerospace, telecoms, government, and research. The tooling — a forked GitHub proof of concept, the Adaptix command-and-control framework, and the FOFA scanner — is entirely public and open source.

SIXZUT, the rootkit that changes the calculus

The most notable element of the campaign is not the flaw itself but the implant behind it. Acronis uncovered JITTERLY, an implant supporting more than 30 post-exploitation commands — shell execution, file transfer, network tunneling, and internal pivoting — and, crucially, SIXZUT, a previously undocumented Linux rootkit embedded in JITTERLY.

SIXZUT does three things that make it dangerous to defenders: it hides the implant’s files, processes, and network connections, it protects the implant from termination, and it relaunches the implant if it is stopped. That is the difference between a compromise you clean up by rebooting and one that survives a reboot. For a team that expects to isolate and reimage a box and be done, a rootkit like this changes the math: you reflash, and you treat the machine as unrecoverable.

The forge as a source-code vault

The victim list explains why a self-hosted forge is a prime target. The most heavily compromised victim is a Canadian renewable-energy company: 22 distinct exploitation sessions, and not just repository theft. Red Heron mapped the entire infrastructure, identified a legitimate employee account, and pulled the full application stack — HR, CRM, the authentication service, intranet, internal reports, and business APIs. Configuration secrets, including JWT tokens, internal tokens, and SSH host keys, were extracted from the Gitea config file; a deploy key tied to the company’s HCM staging environment was also exposed.

The other emblematic victim is a Taiwanese industrial-automation company, from which Red Heron stole hundreds of repositories: a surveillance and monitoring product, a SCADA/HMI tool used in industrial control environments, IoT integrations, a network sniffer, server configurations, and internal business applications. On this single host, Acronis counted more than 130 leftover poc-* directories — as many runs of the exploit chain whose cleanup failed. A Qatar-based target also lost a learning-management platform, an AI chatbot, and workflow-automation tools.

Attribution, and what it changes

The attribution to Red Heron rests on a body of evidence, not certainty: Simplified-Chinese artifacts, targeting methodology, victimology, and observed tradecraft. The reconnaissance databases, target classifications, and FOFA scan metadata recovered from the staging server were written entirely in Simplified Chinese. One detail stands out: Taiwan was consistently coded as country “CN” and region “TW” — treated as a region of China rather than a separate country. A Taiwan-specific list of 477 instances carried the field source: Given authorized website, suggesting it was supplied externally, and an exec[dot]sh script that transferred stolen data off the staging server points to a team-based operation rather than a lone actor.

The target profile — elections, defense, energy, aerospace — signals deliberate collection priorities behind a broader opportunistic sweep. That is the signature of an intelligence operation, not a ransom gang or a miner.

What an operator should do

The lesson extends beyond Gitea. A self-hosted forge — Gitea, Forgejo, GitLab — concentrates source code, secrets, deployment credentials, and often access to connected environments. An initial forge compromise quickly becomes a full infrastructure breach, as the Canadian victim shows.

Three actions come first. Patch immediately: the fixed Gitea release has been out since late July, and any still-vulnerable instance is a declared target. Lock down registration: open registration is what turns a post-auth flaw into unauthenticated access — disable it, or require email confirmation and manual approval. Assume compromise: with a rootkit that hides processes and connections, the working assumption must be that the exposed instance is already breached, which means rotating secrets, reviewing logs, and rebuilding suspect hosts.

Detecting a rootkit that hides its tracks

SIXZUT cannot be detected with the host’s own tools, by definition: a rootkit that hides files, processes, and connections also fools local commands like ps, ls, or ss. Verification therefore has to come from the outside. Three angles work best. First, compare the host from the outside: query the machine from another system — a network scan, or a monitoring agent deployed before the incident — to spot processes or open sockets that are invisible locally. Second, inspect network traffic at the gateway or a port mirror, where the implant’s connections to its C2 show up even if the host hides them. Third, memory and integrity: a memory dump or an integrity check of system binaries, compared against a clean baseline, can reveal hooks and altered binaries.

The simplest option, though, is not to need detection at all: for an exposed, vulnerable Gitea instance, the cost of a clean rebuild is often lower than an uncertain forensic analysis. Rotating secrets — JWT tokens, SSH keys, deploy keys — remains mandatory regardless, since these may have been exfiltrated before the rootkit was even installed.

Verdict

Red Heron is the clearest demonstration yet, in 2026, that a public exploit becomes a state-level campaign within days when the target is a poorly run self-hosted forge.

If you run an internet-facing forge, the update is not optional: you are a month behind and the adversary is actively scanning. If you left open registration enabled, close it before anything else — it is the single factor that separates a repository theft from a mere scan. If you host industrial or sensitive repositories, treat the forge as a priority target and build a secret-rotation plan that does not depend on an already-compromised machine.

References

cve

Linked vulnerabilities

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Chrome 153 fixes CVE-2026-87491, the seventh exploited V8 zero-day of 2026

On September 8, 2026, Google ships Chrome 153, fixing 230 vulnerabilities including CVE-2026-87491, an out-of-bounds write in V8 already exploited in the wild. Update to 153.0.8010.36 or later before the CISA deadline of September 23, and check every Chromium browser in your fleet, Edge, Brave and Opera included.

← Back to the feed

Type at least two characters.

navigate open esc dismiss