Unpatched zero-day in Gogs exploited to hack 700 Git servers

A previously unknown zero-day vulnerability in Gogs, a lightweight, self-hosted Git service, is being actively exploited in the wild.

The flaw, now tracked as CVE-2025-8110, enables remote code execution (RCE) through a symbolic link bypass of an older, patched vulnerability.

The vulnerability came to light during a malware investigation on July 10, 2025, when Wiz analysts uncovered traces of exploitation against a public-facing Gogs server. What began as a routine inspection evolved into the discovery of an active exploitation chain leveraging a critical flaw that allows authenticated users to overwrite arbitrary files outside of the Git repository. The maintainers of Gogs were notified in July, but as of December 1, 2025, no patch has been released, and in-the-wild exploitation is ongoing.

Gogs is a compact Git hosting platform written in Go, often used by organizations seeking a lightweight alternative to GitHub Enterprise or GitLab. It is popular for its minimal resource requirements and ease of deployment, particularly in self-hosted cloud or on-premise setups.

Because many Gogs instances are exposed to the internet and frequently use the default open-registration setting, the platform presents a wide attack surface. Wiz researchers identified over 1,400 Gogs instances exposed publicly, with more than 700 confirmed to be compromised.

The new vulnerability builds upon CVE-2024-55947, a prior RCE flaw discovered by researcher Manasseh Zhou that abused a path traversal weakness in Gogs’ PutContents API. The earlier vulnerability was mitigated by adding basic input validation for file paths.

However, CVE-2025-8110 bypasses that mitigation by exploiting symbolic links, a known vector repeatedly mishandled in Gogs. Because Gogs allows symlinks in repositories and fails to validate their destinations, attackers can trick the system into writing to sensitive files outside the repository context.

The exploitation process is straightforward for any authenticated user:

1. The attacker creates a new Git repository.
2. A symbolic link is committed that points outside the repository, such as to .git/config.
3. Using the PutContents API, the attacker writes to the symlink, causing Gogs to overwrite the target file.
4. By modifying .git/config, particularly the sshCommand, the attacker can achieve arbitrary code execution.

This method requires only default repository creation permissions, enabled by default in most setups, and no privilege escalation.

Widespread exploitation underway

Wiz first noticed the exploit while investigating a malware infection on a customer’s cloud instance running Gogs version 0.13.2, which should have been immune to the original CVE. However, suspicious repositories with random 8-character names, created shortly before the infection, were discovered on the system.

Further scanning of public instances via Shodan revealed a smash-and-grab campaign targeting Gogs. Over 50% of public Gogs servers showed signs of compromise, with indicators suggesting automation and reuse of tooling, potentially by a single threat actor or coordinated group.

The same malware found on the initial infected host was detected across multiple compromised systems. The payload, initially obfuscated with UPX, was written in Go and further protected with garble, a tool that encrypts strings and randomizes identifiers to hinder analysis.

Wiz analysts identified strings linking the malware to Supershell, an open-source command-and-control (C2) framework that uses reverse SSH shells. Supershell is not broadly used but has been spotted in prior attacks, including exploitation of CVE-2023-46747 in F5 BIG-IP devices.

Mitigation and defense

Gogs administrators should assume vulnerability if they are running version ≤ 0.13.3 and the instance is exposed to the internet, and open registration is enabled (default setting).

Recommended actions include:

• Disable open registration unless explicitly required.
• Restrict access to the Gogs instance by placing it behind a VPN or by configuring IP allow-listing.
• Monitor for suspicious activity, such as creation of repositories with 8-character random names or unusual API activity involving PutContents.
• Audit .git/config files and other critical configurations for unauthorized modifications.

Until an official patch is available, hardening instance exposure and monitoring for known indicators remains critical to prevent compromise.