Acronis Threat Research Unit researchers uncovered a state-linked espionage campaign exploiting a critical Gitea RCE vulnerability. A Chinese-speaking threat actor tracked as Red Heron weaponized the security flaw against exposed servers across multiple continents. The attackers breached self-hosted developer platforms to steal private repositories, harvest credentials, and deploy stealthy rootkits.
TL;DR
Threat actors are actively weaponizing a critical remote code execution flaw in unpatched Gitea servers worldwide. The vulnerability allows remote attackers to execute arbitrary system commands by submitting duplicate patch files through public endpoints. Organizations running self-hosted Gitea instances must upgrade immediately to version 1.27.1 to prevent complete host compromise.
- CVE: CVE-2026-60004
- CVSS: 9.8 (Critical · CVSSv3)
- Product: gitea.dev (go)
- Affected: >= 1.17.0, < 1.27.1
- Impact: Gitea: Remote Code Execution via diffpatch Git Hook Installation
- Status: Exploited in the wild
- Patched in: 1.27.1
- EPSS: 86.8% (30-day)
- Action: Update to 1.27.1 now
Track every CVE that hits your stack the moment it's exploited.
Get free email alertsWhy This Threat Matters
Gitea functions as an open-source, self-hosted source code management platform popular among software engineering teams. Sourced estimates from internet scanners show that organizations operate tens of thousands of internet-facing Gitea installations. Consequently, vulnerabilities in these platforms place mission-critical intellectual property at extreme risk. Attackers targeting this Gitea RCE vulnerability gain direct access to proprietary software and developer credentials.
During this campaign, Red Heron scanned 1,386 Gitea instances across seven countries. The threat group maintained structured reconnaissance databases targeting strategic sectors. These sectors included defense contractors, election infrastructure, aerospace companies, and renewable energy providers. Furthermore, confirmed intrusions struck organizations in Canada, Argentina, Taiwan, the United States, and Sri Lanka.
Deep Lateral Movement and Rootkit Deployment
When attackers breach a central code repository, they compromise more than just static source code. The operators extracted configuration secrets, JSON Web Tokens, and private SSH host keys. In one Canadian energy firm, the attacker accessed internal customer relation systems and employee databases.
Even more alarmingly, the intrusion expanded into surrounding virtualization infrastructure in several victim environments. In one Taiwanese deployment, Red Heron progressed from an exposed storage server to root-level administrative access across a three-node Proxmox cluster. The attacker then initiated complete virtual machine backup exports using built-in system tools.
To maintain stealthy persistence, the threat actor deployed a custom C++ backdoor called JITTERLY. Embedded inside the malware was an undocumented Linux shared library rootkit tracked as SIXZUT. This rootkit intercepts file listings, conceals running processes, and hides active network connections. Furthermore, the rootkit protects the backdoor process from termination signals and relaunches it automatically if stopped.
How the Attack Works
The security defect resides inside Gitea’s internal patch processing workflow. As Acronis noted in its report, “The vulnerability sits in Gitea’s diffpatch endpoint.” When processing incoming patch files, the server executes Git commands inside a temporary bare clone. The system runs Git with the three-way merge fallback flag enabled.
An attacker submits the exact same crafted patch twice in succession. The first submission places the payload directly into the Git index. Subsequently, the second submission triggers an add collision during merge processing. This collision forces Git to write the file directly to disk.
The advisory explains the critical mechanism: “Because the clone is bare, the repository root doubles as $GIT_DIR, so a file written to hooks/post-index-change lands directly in Git’s active hook directory and executes as the Gitea service account the next time Git touches the index.”
Furthermore, Gitea enables open account registration by default on fresh installations. Remote attackers do not need existing user credentials on exposed servers. Instead, an intruder simply registers a temporary account, creates a repository, and pushes the malicious patch.
Rapid Exploit Automation
Public proof-of-concept exploit scripts appeared on GitHub shortly after initial disclosure. Red Heron quickly converted these public scripts into an automated attack suite. Acronis researchers observed: “Within days of the vulnerability’s July 2026 disclosure, Red Heron transformed public proof-of-concept code into an automated framework capable of registering accounts, exploiting vulnerable servers, stealing repositories, and removing selected traces.”
The automated framework registered accounts following specific naming patterns. Next, it triggered remote code execution, dumped database tables, and downloaded repositories. Finally, the tool attempted to erase exploit traces from database logs to delay discovery.
Affected Versions
This critical Gitea RCE vulnerability affects all Gitea releases from version 1.17 through version 1.27.0. The security defect holds a maximum severity rating of 9.8 on the CVSS scale. Acronis TRU confirmed active exploitation in the wild across multiple private and government sectors. In addition, functional proof-of-concept exploit code remains widely available in public code repositories.
Patch and Mitigation Steps
Development teams and server administrators must upgrade their Gitea instances to version 1.27.1 immediately. The maintainers resolved the issue by switching temporary clones from bare to non-bare repositories. This architecture change eliminates the hook installation pathway permanently.
Recommended Security Actions
Administrators should apply several immediate protective measures:
- Upgrade all self-hosted servers to Gitea version 1.27.1 or newer.
- Disable open public registration unless your workflow strictly requires it.
- Audit repository directories for suspicious Git hook files created after July 2026.
- Restrict network access to Gitea web interfaces using virtual private networks.
- Inspect host processes and system libraries for unauthorized LD_PRELOAD modifications.
- Rotate all repository deploy keys, access tokens, and administrative database credentials.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!