Acronis Threat Research Unit (TRU) uncovered a multinational campaign in which a Chinese-speaking threat actor, tracked as Red Heron, rapidly weaponized CVE-2026-60004 to compromise internet-facing instances of Gitea, a self-hosted source-code management platform. The activity progressed from source-code theft to persistent access, credential collection, and lateral movement, including root-level access to a three-node Proxmox cluster. TRU traced a Linux implant to Red Heron’s exposed staging server, revealing the actor’s exploitation tools, reconnaissance databases, command history, stolen repositories, and malware. This provided rare visibility into the operation, from target selection and vulnerability weaponization to post-exploitation activity. Red Heron scanned 1,386 Gitea instances across seven countries and maintained a separate dataset of 477 Taiwan-based systems. Targets were classified using Simplified Chinese labels covering defense, elections, energy, aerospace, telecommunications, government, and research. Confirmed compromises affected organizations in Canada, Argentina, Taiwan, the United States, and Sri Lanka. 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 campaign demonstrates how quickly n-day vulnerabilities in self-hosted development platforms can expose source code, credentials, secrets, and connected infrastructure. The staging server also contained JITTERLY, a C++ Linux implant supporting more than 30 post-exploitation commands, including shell execution, file transfer, network tunneling, interactive terminal access, and internal pivoting. Embedded inside it was SIXZUT, a previously undocumented LD\PRELOAD rootkit capable of hiding files, processes, and network connections, preventing the implant from being terminated, and relaunching it if the process is stopped while the binary remains present. TRU assesses with moderate confidence that Red Heron operates within a PRC-linked context, based on Simplified Chinese operational material, its classification of Taiwan as part of China, and targeting aligned with apparent strategic collection priorities. We have not identified sufficient evidence linking Red Heron to a previously tracked threat group.

More details - https://www.acronis.com/en/tru/posts/red-heron-exploits-gitea-n-day-flaw-in-multinational-campaign-exposing-new-linux-rootkit/

Acronis Threat Research Unit (TRU) uncovered a multinational campaign in which a Chinese-speaking threat actor, tracked as Red Heron, rapidly weaponized CVE-2026-60004 to compromise internet-facing instances of Gitea, a self-hosted source-code management platform. The activity progressed from source-code theft to persistent access, credential collection, and lateral movement, including root-level access to a three-node Proxmox cluster. TRU traced a Linux implant to Red Heron’s exposed staging server, revealing the actor’s exploitation tools, reconnaissance databases, command history, stolen repositories, and malware. This provided rare visibility into the operation, from target selection and vulnerability weaponization to post-exploitation activity. Red Heron scanned 1,386 Gitea instances across seven countries and maintained a separate dataset of 477 Taiwan-based systems. Targets were classified using Simplified Chinese labels covering defense, elections, energy, aerospace, telecommunications, government, and research. Confirmed compromises affected organizations in Canada, Argentina, Taiwan, the United States, and Sri Lanka. 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 campaign demonstrates how quickly n-day vulnerabilities in self-hosted development platforms can expose source code, credentials, secrets, and connected infrastructure. The staging server also contained JITTERLY, a C++ Linux implant supporting more than 30 post-exploitation commands, including shell execution, file transfer, network tunneling, interactive terminal access, and internal pivoting. Embedded inside it was SIXZUT, a previously undocumented LD\PRELOAD rootkit capable of hiding files, processes, and network connections, preventing the implant from being terminated, and relaunching it if the process is stopped while the binary remains present. TRU assesses with moderate confidence that Red Heron operates within a PRC-linked context, based on Simplified Chinese operational material, its classification of Taiwan as part of China, and targeting aligned with apparent strategic collection priorities. We have not identified sufficient evidence linking Red Heron to a previously tracked threat group.

More details - https://www.acronis.com/en/tru/posts/red-heron-exploits-gitea-n-day-flaw-in-multinational-campaign-exposing-new-linux-rootkit/

Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users.

In Gitea before 1.21.2, an anonymous user can visit a private user's project.

Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries.

Gitea before 1.22.2 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text.

Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources.

Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.

In Gitea through 1.17.1, repo cloning can occur in the migration function.

In Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log.

In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Due to improper access controls, an attacker could assign any issue to any project in Gitea (there was no permission check for fetching the issue). As a result, the attacker would get access to private issue titles.

Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9.

Gitea before 1.16.7 does not escape git fetch remote.

An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file.

Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5.

The avatar middleware in Gitea before 1.13.6 allows Directory Traversal via a crafted URL.

Missing Authorization in GitHub repository go-gitea/gitea prior to 1.16.4.

An Authentication Bypass vulnerability exists in Gitea before 1.5.0, which could let a malicious user gain privileges. If captured, the TOTP code for the 2FA can be submitted correctly more than once.

An issue exsits in Gitea through 1.15.7, which could let a malicious user gain privileges due to client side cookies not being deleted and the session remains valid on the server side for reuse.

Cross Site Scripting (XSS) vulnerability exists in Gitea before 1.5.1 via the repository settings inside the external wiki/issue tracker URL field.

Gitea before 1.4.3 is affected by URL Redirection to Untrusted Site ('Open Redirect') via internal URLs.

Gitea before 1.11.2 is affected by Trusting HTTP Permission Methods on the Server Side when referencing the vulnerable admin or user API. which could let a remote malisious user execute arbitrary code.

Cross Site Request Forgery (CSRF) vulnerability exists in Gitea before 1.5.2 via API routes.This can be dangerous especially with state altering POST requests.

Server Side Request Forgery (SSRF) vulneraility exists in Gitea before 1.7.0 using the OpenID URL.

Gitea 1.12.x and 1.13.x before 1.13.4 allows XSS via certain issue data in some situations.

Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repoform.go.

DISPUTED The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that the dangerousness of this feature should be documented immediately above the ENABLEGITHOOKS line in the config file). NOTE: The vendor has indicated this is not a vulnerability and states "This is a functionality of the software that is limited to a very limited subset of accounts. If you give someone the privilege to execute arbitrary code on your server, they can execute arbitrary code on your server. We provide very clear warnings to users around this functionality and what it provides."

An issue was discovered in Gitea through 1.11.5. An attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.

Gitea 1.7.0 and earlier is affected by: Cross Site Scripting (XSS). The impact is: Attacker is able to have victim execute arbitrary JS in browser. The component is: go-get URL generation - PR to fix: https://github.com/go-gitea/gitea/pull/5905. The attack vector is: victim must open a specifically crafted URL. The fixed version is: 1.7.1 and later.