Red Heron Gitea RCE: How CVE-2026-60004 Led to Linux Compromise

The Red Heron Gitea RCE campaign exploited CVE-2026-60004, a critical remote code execution vulnerability affecting Gitea versions 1.17 through 1.27.0, to compromise internet-facing Gitea servers.

A threat actor tracked as Red Heron exploited the Gitea RCE vulnerability CVE-2026-60004 against internet-facing Gitea servers. The campaign progressed beyond initial server compromise into source-code theft, credential collection, persistence, and lateral movement. Acronis Threat Research Unit linked the activity to a Chinese-speaking threat cluster.

CVE-2026-60004 affects Gitea 1.17 through versions before 1.27.1. The vulnerability abuses Gitea’s diffpatch API to install and execute a Git hook from repository-controlled content. Gitea patched the issue in version 1.27.1.

The campaign matters because Gitea can sit close to source code, deployment infrastructure, application secrets, and other internal systems. In this case, Red Heron reportedly turned access to exposed Gitea servers into a broader Linux infrastructure compromise.

Red Heron Gitea RCE campaign at a glance

The CVE record gives CVE-2026-60004 a CVSS v3.1 score of 9.8 and identifies versions 1.17 through versions before 1.27.1 as affected. CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) Catalog on August 25, 2026.

How CVE-2026-60004 Turns a Gitea Patch Into a Git Hook

The defining mechanism behind CVE-2026-60004 sits inside Gitea’s diffpatch functionality.

Gitea processes attacker-controlled patches inside a temporary bare Git clone. With Git 2.32 or later, submitting the same crafted patch twice can create an add/add collision. Git’s three-way fallback can then write an executable post-index-change file into the bare repository’s hooks directory.

Because the repository root of a bare clone is also $GIT_DIR, that file becomes a live Git hook. Git invokes the hook during the index operation, causing attacker-controlled commands to execute as the Gitea service account.

The exploit trigger requires Git 2.32 or newer, an enabled diffpatch route, and a writable and executable temporary filesystem. The attacker also needs ordinary repository write access. With open registration enabled, an unauthenticated visitor can obtain that access by registering an account and creating a repository.

Open registration is not inherently required for exploitation. Instead, it provides one path through which an unauthenticated visitor can obtain the required repository write access.

This distinction matters. CVE-2026-60004 is fundamentally a repository-write-to-server-code-execution vulnerability. Open registration can create a path to that prerequisite on exposed deployments.

How the Red Heron Gitea RCE Expanded Into Linux Infrastructure

Acronis Threat Research Unit said Red Heron rapidly weaponized CVE-2026-60004 against internet-facing Gitea instances. The operation progressed from source-code theft into persistent access, credential collection, and lateral movement.

Reporting on the Acronis investigation says the actor scanned 1,386 Gitea instances across seven countries, while maintaining another dataset containing 477 Taiwan-based systems. Researchers confirmed compromises at 13 organizations across Canada, Argentina, Taiwan, the United States, Qatar, and Sri Lanka.

Targets spanned sectors including defense, energy, aerospace, telecommunications, government, public safety, elections, and research.

The campaign eventually reached infrastructure beyond the original Gitea servers. Acronis reported lateral movement and deeper infrastructure access, showing why a compromised development platform should not be treated as an isolated web-server incident.

JITTERLY and SIXZUT Added Persistence and Concealment

Analysis of infrastructure associated with Red Heron revealed a C++ Linux implant called JITTERLY.

JITTERLY provides more than 30 post-exploitation commands covering capabilities such as:

• shell execution
• file transfer
• process termination
• network tunneling
• interactive terminal access
• internal pivoting

Researchers also identified SIXZUT, a previously undocumented LD_PRELOAD rootkit associated with the backdoor. SIXZUT patches Linux functions to conceal files, processes, and network connections. It can also interfere with attempts to terminate malicious components and help relaunch them after removal.

Because LD_PRELOAD rootkits can intercept user-space library calls, ordinary process or file listings may return manipulated results and hide malicious artifacts. File-integrity monitoring can still surface unauthorized changes, but defenders should not rely on a single user-space view when investigating a suspected rootkit.

That changes the incident-response problem. Removing the original Gitea exploit path does not establish that a previously compromised server is clean.

Teams investigating affected hosts should therefore treat patching and post-compromise investigation as separate tasks.

What Enterprises Should Do About CVE-2026-60004

Upgrade Gitea first. Gitea identifies 1.27.1 as the patched version, while all releases from 1.17 through 1.27.0 fall within the affected range. Organizations should deploy 1.27.1 or a later supported release.

Then investigate whether vulnerable instances were exposed during the exploitation window.

Security teams should:

• Inventory internet-facing and internally accessible Gitea instances.
• Review whether open registration was enabled.
• Audit accounts and repository write permissions.
• Review Gitea hosts for unexpected processes, files, hooks, outbound connections, and persistence.
• Rotate credentials and application secrets exposed to a compromised Gitea service account.
• Investigate connected infrastructure before returning affected systems to service.
• Review source repositories and deployment pipelines for unauthorized changes.

The Gitea advisory notes that successful exploitation can expose application secrets, environment secrets, mounted repositories, database credentials, OAuth credentials, and reachable internal services. The actual exposure depends on each deployment’s isolation and Gitea service-account privileges.

How Hexnode UEM Supports Linux Response to the Red Heron Campaign

The response operates at two different layers. Server-level remediation requires teams to update Gitea and investigate the affected application and infrastructure. Endpoint fleet governance can use Hexnode UEM to manage supported Linux systems, monitor compliance, and deploy validated administrative scripts across managed hosts.

For organizations managing supported Linux systems, Hexnode UEM provides centralized Linux device management. Hexnode UEM supports Linux endpoint management, including compliance policies and platform-specific management capabilities on supported Linux distributions.

Track Linux security posture

Administrators can use compliance policies to identify managed Linux systems that fall outside defined organizational requirements. This can help teams surface systems requiring administrative attention during a wider remediation effort.

Run incident-specific administrative scripts

Hexnode UEM supports remote Bash script execution on supported Linux endpoints. During an incident like Red Heron, administrators can use validated custom scripts for approved investigation or administrative workflows across managed systems.

Hexnode Genie can help administrators generate scripts from natural-language prompts. Administrators can then review and refine the generated code in the Script Editor before saving it to the Hexnode Repository.

Before deployment, administrators should manually review and test AI-generated scripts on a test system. Separately, Hexnode UEM supports deploying validated Bash scripts to supported Linux endpoints through the Execute Custom Script action.

However, custom scripting and Hexnode Genie are administrative execution and script-generation capabilities, not proof that Hexnode detects JITTERLY, SIXZUT, or exploitation of CVE-2026-60004.

Likewise, Hexnode UEM does not replace the Gitea application upgrade. Gitea administrators should update the server through their established application or deployment workflow.

Featured resource

Linux Platform Capability Statement

Explore how Hexnode UEM helps IT teams centrally manage supported Linux endpoints.

Download the infographic

Patch Gitea, Then Investigate Beyond Gitea

The Red Heron campaign demonstrates the risk created when a source-code platform also becomes an execution foothold.

CVE-2026-60004 allowed repository-controlled content to become an executable Git hook on vulnerable Gitea servers. Red Heron then reportedly expanded access into source-code theft, persistence, credential collection, and lateral movement.

Organizations running affected versions should upgrade to Gitea 1.27.1 or later and investigate systems that may already have been compromised. Where JITTERLY or SIXZUT is suspected, simply closing the initial vulnerability is not sufficient to establish host integrity.

For managed Linux infrastructure, Hexnode UEM can support device management, compliance monitoring, and custom administrative script execution on supported Linux endpoints. The Gitea patch and incident investigation must still happen at the affected server and infrastructure layers.