Red Heron Exploits Critical Gitea RCE to Breach 13 Organizations

A suspected China-linked threat actor tracked as Red Heron has exploited a critical Gitea vulnerability to compromise development platforms, steal repositories, harvest credentials, and penetrate connected infrastructure.

Acronis Threat Research Unit identified 13 confirmed organizational compromises across Canada, Argentina, Taiwan, the United States, Qatar, and Sri Lanka. Targets operated in sectors including defense, elections, energy, aerospace, telecommunications, government, public safety, and research.

The campaign reached far beyond source-code theft. In one Taiwanese environment, Red Heron obtained root-level administrative control over a three-node Proxmox cluster after entering through a vulnerable Gitea server.

Red Heron Combined Mass Scanning With Strategic Targeting

Red Heron scanned 1,386 internet-facing Gitea instances across seven countries. The actor also maintained a separate dataset containing 477 systems in Taiwan, although it is not known whether those systems overlapped with the broader scan results.

The 13 confirmed compromises were distributed as follows:

• Four organizations in Taiwan
• Four in the United States
• Two in Canada
• One in Argentina
• One in Qatar
• One in Sri Lanka

The seventh country covered by the scanning operation has not been identified.

While some activity resembled opportunistic internet-wide exploitation, the selection and labeling of targets showed a more deliberate intelligence-collection effort. The affected sectors included organizations likely to hold sensitive technology, infrastructure data, government information, or privileged access to other networks.

TRU assessed the actor as operating in a China-linked context with moderate confidence. That assessment is not a definitive attribution to the Chinese government. It rests on Red Heron’s use of Simplified Chinese labels, its consistent classification of Taiwan as part of China, and targeting that aligned with perceived Chinese intelligence priorities.

Related activity also involved an India-based overseas education consultancy and a managed IT-services provider in the United States. These organizations were targeted through associated infrastructure, but they are not described as additional confirmed compromises beyond the 13-country total.

CVE-2026-60004 Enables Unauthenticated Remote Code Execution

The initial-access vector was CVE-2026-60004, a remote-code-execution vulnerability affecting Gitea versions earlier than 1.27.1.

The flaw resides in Gitea’s diffpatch API and permits an attacker to install a Git hook. Because Git hooks can execute commands in response to repository operations, abusing this mechanism gives the attacker a path to run code on the underlying server.

CVE-2026-60004 has a CVSS v3 score of 9.8 and is classified as CWE-94, improper control of code generation. Its vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The vulnerability is remotely reachable, requires low attack complexity, and does not require an existing account or user interaction. Successful exploitation can have a high impact on confidentiality, integrity, and availability.

The vulnerability was disclosed in July 2026. Red Heron began converting publicly available exploit material into an automated Python framework named exp_enhanced.py on July 29, 2026, according to reporting on the campaign.

That framework automated several stages that would otherwise require separate operator actions: registering accounts, exploiting vulnerable servers, stealing repositories, and removing selected evidence. This reduced the time between finding an exposed instance and collecting its data.

Repository Access Became a Route Into Internal Networks

A self-hosted development platform can contain substantially more than application source code. Repositories frequently include deployment files, server addresses, API tokens, SSH material, integration credentials, and configuration secrets. Even when individual secrets are outdated, they can reveal naming conventions and network structure.

Red Heron used compromised Gitea systems as collection points and, where possible, as bridges into victim environments. Observed activity progressed through repository theft, credential harvesting, persistence, internal reconnaissance, and lateral movement.

At a Taiwanese industrial-automation company, the actor exfiltrated hundreds of repositories. The stolen material covered a SCADA/HMI product, IoT-platform integrations, a network sniffer, server configurations, surveillance and monitoring software, and internal business applications.

The intrusion later expanded to root-level access across three Proxmox nodes. Root control of the virtualization hosts could give an attacker broad visibility and administrative power over workloads running on the cluster, although the full consequences in this case have not been disclosed.

A Canadian renewable-energy company experienced extensive infrastructure mapping and repository theft. Exposed material included configuration secrets, internal tokens, SSH host keys, and proprietary applications.

At an Argentine quantitative-trading company, Red Heron extensively enumerated the organization’s infrastructure. A Qatar-based victim lost repositories associated with a learning-management platform, an AI chatbot, workflow-automation tools, and WordPress plugins.

These incidents show why patching the Gitea server alone may not end an intrusion. Credentials and keys obtained before remediation can remain useful afterward.

JITTERLY and SIXZUT Supported Persistent Linux Access

Infrastructure attributed to Red Heron contained a Linux implant written in C++ and named JITTERLY. The malware supports more than 30 post-exploitation commands, including shell execution, file transfer, process termination, network tunneling, interactive terminal access, and internal pivoting.

A researcher using the alias “dmpdump” documented JITTERLY in July 2026 and identified overlaps with the AdaptixC2 agent. The available information does not establish whether Red Heron developed the implant or adopted existing code.

The same staging environment hosted SIXZUT, a previously undocumented Linux rootkit based on LD_PRELOAD. This technique causes a malicious shared library to load before legitimate libraries, allowing it to intercept calls made by programs on the system.

SIXZUT patches 15 Linux functions to hide files, processes, and network connections. It is also designed to resist removal by relaunching itself after termination. Those capabilities can conceal command-and-control traffic and malicious processes from routine administrative checks.

Shared infrastructure connected the Gitea campaign to attacks against 18 Joomla websites in 10 countries. A Python script named exp.py was used for the Joomla activity before the operator incorporated public CVE-2026-60004 exploit code into its Gitea tooling. This points to a broader web-exploitation operation rather than activity confined to one software product.

CISA Added the Flaw to KEV With a Three-Day Deadline

CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026. The remediation deadline for U.S. federal agencies was August 28, 2026.

The short deadline reflected confirmed exploitation rather than a theoretical risk. Under the recorded action, agencies must apply vendor mitigations while complying with BOD 26-04, “Prioritizing Security Updates Based on Risk,” and CISA’s Forensics Triage Requirements.

Applicable BOD 26-04 guidance also covers cloud services. If effective mitigations are unavailable, CISA directs agencies to discontinue use of the affected product. Organizations remain responsible for evaluating each asset’s internet exposure and meeting the applicable patching requirements.

All Gitea releases earlier than 1.27.1 are affected. Operators should upgrade to version 1.27.1 or later, following Gitea’s instructions and their own change-control procedures.

Patching Must Be Paired With Compromise Assessment

Organizations should first inventory every Gitea deployment, including forgotten test servers and instances exposed through reverse proxies. Any affected system accessible from the internet should receive immediate priority.

Defenders should then investigate whether exploitation occurred before the upgrade. Useful areas of review include:

• Unexpected Gitea account registrations
• Git-hook creation or modification
• Unusual diffpatch API activity
• Bulk repository access or outbound transfers
• Newly created SSH keys or altered authorized-key files
• Exposure or use of configuration secrets and internal tokens
• Unexpected Proxmox administrative actions
• Suspicious Linux processes, tunnels, or outbound connections
• Unrecognized LD_PRELOAD configuration and shared libraries
• Files or commands associated with exp_enhanced.py, exp.py, JITTERLY, or SIXZUT

Secrets stored in affected repositories should be treated as potentially exposed. Relevant API tokens, passwords, SSH keys, signing material, and service credentials should be rotated, with authentication logs reviewed for subsequent use.

Systems showing signs of SIXZUT may not provide trustworthy process or network output because the rootkit can manipulate user-space visibility. In those cases, responders should use known-clean forensic tooling and collect evidence before rebuilding affected hosts.

The central risk is not limited to the Gitea application. Once a development server exposes source code, credentials, and infrastructure configuration, the compromise can spread into the systems that build, deploy, host, or manage an organization’s software.