A critical zero‑day vulnerability in Gogs, a lightweight self‑hosted Git service written in Go and widely deployed as an alternative to GitLab and GitHub Enterprise, has triggered a large‑scale exploitation campaign. Tracked as CVE-2025-8110, the flaw enables remote code execution (RCE) and has already led to the compromise of hundreds of Gogs servers worldwide.
Critical Gogs CVE-2025-8110 Remote Code Execution Vulnerability
The vulnerability CVE-2025-8110 is rooted in a path traversal weakness within the Gogs PutContents API. Path traversal bugs occur when an application does not properly validate file paths, allowing an attacker to read or overwrite files outside the intended directory structure, typically using sequences like ../ to “climb” the filesystem.
In this case, the flaw effectively bypasses the protections introduced for a previous RCE issue, CVE-2024-55947. After that earlier bug was patched, Gogs added checks to prevent directory traversal. However, according to research by Wiz, those checks did not correctly handle symbolic links (symlinks), leaving a critical gap.
How CVE-2025-8110 Abuses Path Traversal and Symlinks
The exploitation chain hinges on the interaction between repository content and filesystem permissions. An attacker can:
First, create a repository that contains symlinks pointing to sensitive files located outside the repository directory tree. These symlinks are treated as normal files by higher‑level logic but ultimately resolve to arbitrary paths on the underlying filesystem wherever the Gogs process has write access.
Second, by invoking the vulnerable PutContents API, the attacker uploads or modifies content that appears to be stored “inside” the repository. In reality, Gogs follows the symlink and writes the data to the external file referenced by the link, effectively overwriting files outside the repository boundary.
The most impactful scenario involves overwriting Git configuration files, particularly the sshCommand setting. By manipulating this parameter, an attacker can force Git operations to execute arbitrary system commands whenever certain Git actions are triggered. This results in full remote code execution on the Gogs host, with privileges equivalent to the Gogs service account.
Scale of the Attacks Against Internet‑Exposed Gogs Servers
Over 700 Compromised Gogs Instances and Evidence of Automation
Wiz researchers report that they first observed malicious activity linked to CVE-2025-8110 in July 2025 during an investigation on a customer’s Gogs server. Subsequent internet‑wide scanning identified more than 1,400 publicly accessible Gogs instances, with over 700 already showing clear signs of compromise.
Compromised servers shared a distinctive indicator: the presence of repositories with random eight‑character names, all created within a narrow timeframe in July 2025. This consistent pattern strongly suggests the use of automated scanning and exploitation tools, likely operated by a single threat actor or coordinated group rather than opportunistic, isolated attacks.
An important enabler of the campaign is the common use of the default Open Registration setting. Where this option is left enabled, any external user can freely register, create repositories, and directly exploit the vulnerability—without needing stolen credentials or privileged access. This dramatically expands the attack surface for internet‑facing Gogs deployments.
Supershell‑Based Malware and Command‑and‑Control Infrastructure
Post‑exploitation analysis shows that the threat actor deployed malware built on top of the open‑source Supershell C2 framework. Supershell simplifies the creation of reverse SSH shells over web services, providing attackers with a flexible and resilient channel for remote administration of compromised machines.
Network telemetry from affected environments indicates that infected hosts communicated with a command‑and‑control (C2) server at 119.45.176[.]196. This centralized infrastructure is typical of both targeted and large‑scale intrusion campaigns, allowing operators to maintain persistence, push additional tooling, and pivot deeper into the victim environment as needed.
Risk Assessment and Practical Mitigations for Gogs Administrators
Immediate Hardening Steps for Gogs Servers
According to the disclosed timeline, Gogs maintainers were notified of CVE-2025-8110 on 17 July 2025 and confirmed the issue on 30 October, announcing that a fix was in development. A second exploitation wave reportedly began on 1 November 2025, before an official patch was available, underscoring the need for immediate compensating controls.
Recommended defensive measures for organizations running Gogs include:
1. Disable Open Registration wherever possible. If public self‑service sign‑up is not strictly required, turn it off and switch to controlled account provisioning via administrators, SSO, or LDAP. Reducing anonymous account creation significantly limits exposure to automated exploitation.
2. Restrict network exposure of Gogs. Ideally, remove direct internet access to Gogs and place it behind VPN, zero‑trust access, or at least strict firewall rules. Public access to administrative and API endpoints should be minimized and carefully monitored.
3. Hunt for indicators of compromise (IoCs). Administrators should:
- Review logs for unusual or high‑volume usage of the PutContents API.
- Search for repositories with random eight‑character names created in a short time window.
- Inspect Git configuration files, especially sshCommand, for unauthorized or unexpected modifications.
- Monitor outbound SSH and HTTP(S) connections to unfamiliar destinations, including 119.45.176[.]196 and similar suspicious IPs.
4. Prepare for rapid patching and ongoing security hygiene. Once an official Gogs update addressing CVE-2025-8110 is released, it should be deployed without delay, following proper change‑management procedures. Beyond this specific issue, organizations should regularly audit Gogs configurations, disable unnecessary defaults, enforce least‑privilege access to repositories, and integrate code‑hosting services into centralized logging and threat‑detection workflows.
The exploitation of CVE-2025-8110 highlights how vulnerabilities in source code management platforms can quickly escalate into systemic risk for development and DevOps environments. By limiting public exposure, tightening identity and access controls, and institutionalizing continuous monitoring, organizations can significantly reduce the likelihood that the next zero‑day in a self‑hosted Git platform will lead to a long‑term compromise of their software supply chain.
