Red Heron Cloned a Gitea PoC on July 29. Our Harvester Caught the Same Repo the Same Day, We Called the Open-Registration Default July 31, CISA Cataloged It August 25. Acronis Named the Actor Today.
Acronis's Threat Research Unit published the anatomy of a campaign today and named its operator Red Heron: a cluster they assess with moderate confidence as PRC-linked, working from an exposed staging server that gave the researchers something rare, the operator's own tooling, command history, reconnaissance databases and stolen repositories. The bug is Gitea CVE-2026-60004. The count is thirteen confirmed compromises across six countries, out of 1,386 Gitea instances scanned and a separate list of 477 Taiwanese systems, classified in Simplified Chinese into defense, elections, energy, aerospace, telecommunications, government and research.
We checked our own timestamps before writing a word, because the last time we wrote "in our feed since" without doing that, we published a two-month lead that was actually a one-day lag. Here is what holds and what doesn't.
The lead that holds
On July 29, 2026, a GitHub user published a proof of concept for CVE-2026-60004 under the name HORKimhab. Our exploit harvester, which runs every six hours against new repositories, recorded that repository with a creation timestamp of July 29 and harvested it the same day. That timestamp is GitHub's, not ours. It's the line.
Acronis's report says Red Heron cloned that exact repository on July 29 and started building on top of it, testing script versions against lab infrastructure and then, by July 30, against live targets outside Taiwan. The operator's .viminfo on the staging server gave them that sequence. So the first public PoC and the first adversary use of it are the same day, and our harvester had the receipt on that day. Nine more PoC repositories followed through August; the harvester has all of them, including one created this morning.
On July 31 we published a post about the bug whose title was the whole argument: Gitea shipped a 9.8 that needs an account, and Gitea also ships with anyone being able to make one. The vulnerability sat in the diffpatch API and required repository write access, which sounds like a mitigation until you remember that open registration is on by default. Register, create a repository, submit the payload, and Gitea's own service account executes it the next time Git touches the index. That's the paragraph we wrote on July 31. Acronis's description of Red Heron's exp_enhanced.py, six weeks later: ingest a JSON target list, auto-register accounts with a word_word_NNN naming pattern, exploit each target, dump the repositories straight off the filesystem, clean up the traces. The account requirement was never a mitigation. It was step one.
CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog on August 25. That is 27 days after the first public PoC and 25 days after our post. Our August 27 audit of every CVE cataloged that month already listed it among the seven we were early on, so this is not a new claim; it's the same claim with the adversary's own timeline now confirming which side of the line the PoC was on.
The lead that is not ours
The actor is Acronis's. The thirteen victims are Acronis's. The JITTERLY implant, a C++ Linux backdoor with a hardcoded command-and-control address baked into its .data section, and the SIXZUT rootkit it decrypts and drops through /etc/ld.so.preload, are Acronis's. The staging-server forensics that make this report unusually good are Acronis's. We had no idea who was on the other end of that PoC until this morning, and we are not going to pretend otherwise. Our lead is on the vulnerability and the mechanism. Theirs is on the campaign.
Two of their indicators were already in our corpus, though, and both are worth a sentence because neither is our work. On July 20, nine days before Red Heron started exploiting, a researcher on X flagged iot.981666.xyz, a sibling host on the same parent domain as the JITTERLY C2, s2.981666.xyz. It reached our feed through TweetFeed. And on August 6, ThreatFox listed the staging server, 72.11.138.109, on port 8084 as a VShell botnet command server. So the infrastructure was partially visible in free feeds before anyone had a name for the operator, which is the shape we keep finding: the perimeter of a campaign leaks into the commons weeks before the campaign gets a report. Distribution value, not detection. We cite it; we don't claim it.
What went into the feed
Acronis published two SHA-256 hashes, a C2 domain, its parent, one related domain, and the staging IP. All six went in this afternoon under source manual-batch-red-heron-gitea, attributed to Red Heron, with the CVE and the Acronis and Hacker News references attached, confidence 80 to 95. The C2 domain and both related domains landed and read back within minutes; the staging IP and the two hashes were queued behind the index's embedder and confirmed by direct read-back before this post went live. If you pull our domains list after 23:30 UTC on September 14 and s2.981666.xyz is not in it, tell us, because that would be the next false green.
What did not go in: the 1,386 scanned Gitea instances and the 477 Taiwanese systems are victims, not threats, and Acronis correctly did not publish them. The host indicators, libglthread.so.2, the .ld_aux_cahe config, the /tmp/.X11-unix.lk lock file, the ADLGTBL1 magic header, are in the report and are what you hunt with on the box, not what you block at the edge.
What to do if you run Gitea
Turn off open registration unless you have a reason it must be on, and if it must be on, know that any authenticated-only CVE against your instance is unauthenticated in practice. Patch to the July release or later. Then hunt, not scan: SIXZUT hides itself from ls and find on the live host, so use disk images or EDR telemetry, check /etc/ld.so.preload for entries you didn't put there, audit authorized_keys on every account, and treat every credential, JWT and SSH host key that was ever stored in a compromised Gitea instance as disclosed. Acronis's advice on confirmed compromise is the right one: rebuild rather than clean, because the rootkit restores the implant if you kill it while the binary is still on disk. And assume the repositories were taken, because the operator's tooling dumped them off the filesystem, and read them for embedded secrets before you call it contained.
The thing we keep learning
A public PoC on a Tuesday is the earliest reliable signal that a bug will be in the catalog by the end of the month, and for the 27 days between those two events, the only thing standing between an open-registration Gitea and a Chinese-language target list was whether the operator had gotten to it yet. The catalog is authoritative and late. The PoC is noisy and early. We read the PoC.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=red-heron-cloned-a-gitea-poc-on-july-29-our-harvester-caught-the-same-repo-the-same-day-we-called
Comments