Executive Summary

• While investigating a malware infection on a customer workload, Wiz Research discovered an active zero-day vulnerability in Gogs, a popular self-hosted Git service.

• A symlink bypass (CVE-2025-8110) of a previously patched RCE (CVE-2024-55947) allows authenticated users to overwrite files outside the repository, leading to Remote Code Execution (RCE).

• We identified over 700 compromised instances public-facing on the internet.

• Update: As of January 23, 2026, a fix has been issued in version v0.13.4.

Introduction

On July 10th, the Wiz Threat Research team observed malware findings on public-facing instances of Gogs, a popular self-hosted Git service. What began as a routine investigation into an infected machine turned into the accidental discovery of a live zero-day vulnerability.

During our analysis of the exploitation attempts, we identified that the threat actor was leveraging a previously unknown flaw to compromise instances. We responsibly disclosed this vulnerability to the maintainers. The maintainers have addressed this vulnerability in the v0.13.4 release.

What is Gogs

Gogs is a popular self-hosted Git service written in Go. It provides a lightweight alternative to GitLab or GitHub Enterprise and is popular among developers for its ease of deployment and minimal resource usage. Because it is self-hosted, it is frequently found in both on-premise and cloud environments, often exposed to the internet to enable remote collaboration. 

The popularity of Gogs makes it a significant target. In our external scan, we identified over 1,400 Gogs servers publicly exposed to the internet. Many of these instances are configured with "Open Registration" enabled by default, creating a massive attack surface for the vulnerability described below.

What is CVE-2025-8110?

CVE-2025-8110 is, effectively, a bypass for an earlier RCE vulnerability (CVE-2024-55947) originally discovered by ManassehZhou.

The History (CVE-2024-55947)

The previous flaw abused a path traversal weakness in the PutContents API. It allowed an attacker to write files outside the git repository directory, granting the ability to overwrite sensitive system files or configuration files to achieve code execution. The maintainers addressed this by adding input validation on the path parameter.

The Bypass (CVE-2025-8110)

Unfortunately, the fix implemented for the previous CVE did not account for symbolic links.

This new bypass relies on two key facts:

1. Git, and subsequently Gogs allows symbolic links to be used in git repositories, and those symbolic links can point to objects outside the repository

2. Gogs API allows file modification outside of the regular git protocol, and its previous iteration of this implementation didn’t properly check for symbolic link abuse.

The Gogs API allows file modification outside of the regular git protocol, and while it now validates path names, it fails to validate the destination of a symbolic link. Because Gogs respects standard Git behavior, it allows users to commit symbolic links to repositories. The vulnerability arises because the API writes to the file path without checking if the target file is actually a symlink pointing outside the repo. This effectively renders the previous path validation useless if a symlink is involved.

The Attack Chain

The exploitation process is trivial for any user with repository creation permissions (enabled by default):

1. The attacker creates a standard git repository.

2. They commit a single symbolic link pointing to a sensitive target.

3. Using the PutContents API, they write data to the symlink. The system follows the link and overwrites the target file outside the repository.

4. By overwriting .git/config (specifically the sshCommand), the attacker can force the system to execute arbitrary commands.

This continues a troubling pattern in Gogs (see CVE-2024-56731, CVE-2024-54148), where symbolic link handling is repeatedly exploited to alter internal files.

Exploitation in the wild

Our investigation began with a single malware infection on a customer's cloud workload.

We identified a publicly exposed Gogs service (version 0.13.2) running on the compromised host. This version should have been immune to CVE-2024-55947. However, the web interface revealed:

• Several suspicious repositories created exactly five days prior.

• Timestamps matching the malware infection.

• Repository names consisting of random 8-character strings.

It is important to note that while these artifacts are necessary for the attack, a more sophisticated attacker could have marked these repositories as private or deleted them immediately after exploitation. The visibility of these artifacts suggests an automated, "smash-and-grab" style campaign.

Widespread compromise

Expanding our search via Shodan to review all exposed instances mentioned earlier, we found:

• ~1,400 total exposed instances

• 700+ confirmed compromised instances

In other words, over 50% of the exposed instances we observed showed signs of compromise. All infected instances shared the same pattern: 8-character random owner/repo names created within the same short time window (July 10th). This suggests that a single actor, or perhaps a group of actors all using the same tooling, are responsible for all infections.

Malware deep-dive

As mentioned in the previous sections this investigation started with a single malware infection, we later found the exact same malware on multiple compromised servers, again confirming our assumption that this vulnerability is being exploited by a single actor.

The payload had multiple layers of obfuscation designed to evade detection:

The first a simple UPX packing:

Under the packed UPX we discovered that the malware was written in go, compiled with the garble tool. That means that all class names are randomized and most string literals are encrypted on disk and only decrypted during run time heavily limiting static analysis of the file.

We then used Mandiant’s brilliant ungarbler tool, which extracts all string literals from garbled binaries, revealing multiple indicative strings that allowed us to pinpoint the library our malware originated from.

These unique strings led us to discover that the payload was created using the Supershell framework.

Supershell is an open-source Command and Control (C2) platform whose primary function is to establish a reverse SSH shell that communicates over web services. This mechanism grants attackers remote control and the ability to execute arbitrary code on a compromised system. Although Supershell is not widely known or commercially popular, it has been observed in campaigns by threat actors who leverage it after exploiting initial access vulnerabilities, such as CVE-2023-46747 in F5 BIG-IP devices.

From the Supershell payload we were also able to extract the attack groups C2 server

`119.45.176[.]196`.

Disclosure Timeline

The patch status for this vulnerability is critical. Despite responsible disclosure, the vulnerability remains unpatched in the main branch as of this writing.

• July 10, 2025: First indication of exploitation observed by Wiz.

• July 15, 2025: Discovery of Supershell malware on a vulnerable machine.

• July 17, 2025: Vulnerability reported to Gogs maintainers.

• Oct 30, 2025: Acknowledgment of the vulnerability by Gogs maintainers.

• Nov 1, 2025: A second wave of attacks observed in the wild.

• Dec 10, 2025: Original blog post released. The vulnerability was not yet fixed.

• Jan 23, 2026: Gogs releases version v0.13.4, fixing the vulnerability.

Remediation & Mitigation

Are you vulnerable? If you are running a Gogs server (version <= 0.13.3) that is:

1. Exposed to the internet.

2. Has open-registration enabled (default setting).

Then you are vulnerable to CVE-2025-8110.

Immediate Actions:

1. Upgrade Gogs immediately: Install version v0.13.4 or later to patch the vulnerability.

2. If you cannot upgrade immediately, disable open-registration.

3. Limit internet exposure. Place self-hosted Git services behind a VPN or use an allow-list for IP addresses.

4. Look for the creation of repositories with random 8-character names or unexpected usage of the PutContents API.

How can Wiz help?

Wiz can help detect attacks like the one described in this blog in multiple ways: 

1. Our agentless malware detection detects these types of evolving threats using our proprietary YARA rules catalog.

2. The Wiz Runtime Sensor detects events and behaviors associated with this threat and similar ones

3. Our agentless vulnerability detection surfaces instances of this vulnerability across cloud and code environments.

Indicators of compromise (IoC)