Critical Gogs RCE (CVE-2025-8110) Under Active Exploitation - What You Must Do Now

Overview

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has officially listed a critical remote code execution (RCE) vulnerability in the popular self-hosted Git service Gogs as a Known Exploited Vulnerability (KEV). The flaw, identified as CVE-2025-8110, enables unauthenticated threat actors to execute arbitrary commands on the host running Gogs by abusing a path‑traversal issue in the PutContents API. With no vendor‑issued patch available, organizations must act now to contain the risk.

Technical Details

CVE-2025-8110 (CVSS 8.7) is a classic case of improper symbolic‑link handling combined with insufficient path sanitisation. The attack chain works as follows:

• Step 1 - Repository Creation: The attacker creates a new Git repository on the vulnerable Gogs instance.
• Step 2 - Symlink Injection: Within that repository, the attacker commits a symbolic link (symlink) that points to a sensitive file outside the repository, such as /etc/gitconfig or /root/.ssh/authorized_keys.
• Step 3 - PutContents Abuse: Using the PUT /api/v1/repos/:owner/:repo/contents/:path (PutContents) endpoint, the attacker writes arbitrary data to the path that resolves to the symlink. The Gogs backend follows the symlink and writes directly to the target file on the host filesystem.
• Step 4 - Code Execution: By overwriting configuration files—most notably the sshCommand setting in gitconfig—the attacker injects a malicious command that executes with the privileges of the Gogs process (often root or a privileged service account). This grants full remote code execution on the host.

Wiz’s research indicates that the exploit bypasses mitigations introduced for the earlier CVE-2024-55947, effectively turning a previously mitigated path‑traversal into a full‑blown RCE vector.

Impact Analysis

The vulnerability primarily affects:

• Self‑hosted Gogs deployments – on‑premises servers, cloud VMs, or containerised environments.
• CI/CD pipelines that rely on Gogs for source control, webhooks, or automated builds.
• Development teams that expose Gogs to the internet without strict access controls.

According to Censys data, over 1,600 internet‑exposed Gogs instances exist, with the largest concentrations in China (991), the United States (146), Germany (98), Hong Kong (56), and Russia (49). Wiz has already observed exploitation against roughly 700 instances, confirming that threat actors are actively weaponising the flaw.

Potential consequences include:

• Full system compromise, enabling data exfiltration, ransomware deployment, or lateral movement.
• Supply‑chain attacks: compromised source code can be silently altered, inserting backdoors into downstream applications.
• Loss of integrity for internal developer workflows and loss of confidence in the organization’s DevSecOps posture.

Timeline of Events

• Late 2025 – Initial discovery of the path‑traversal weakness in the PutContents API (CVE-2025-8110).
• Early January 2026 – Wiz reports active exploitation in the wild; zero‑day attacks observed.
• January 13, 2026 – CISA publishes an advisory and adds CVE-2025-8110 to the KEV catalog.
• Mid‑January 2026 – Gogs maintainers merge a pull‑request fixing the symlink handling; images will be updated in upcoming releases.
• February 2, 2026 – Federal Civilian Executive Branch agencies required to implement mitigations.

Mitigation & Recommendations

Because an official patch is not yet released, organisations must apply defence‑in‑depth controls:

1. Network Segmentation: Isolate Gogs servers from the internet. Use VPNs or bastion hosts and enforce strict allow‑lists for API access.
2. Web Application Firewall (WAF) Rules: Block or scrutinise requests to the /api/v1/repos/*/contents/* endpoint from unauthenticated sources. Consider rate‑limiting and payload inspection for suspicious .. sequences or symlink‑related patterns.
3. Disable Open Registration: Turn off the default open‑registration setting to prevent unauthenticated users from creating repositories.
4. Restrict File System Permissions: Run Gogs under a non‑privileged user and ensure critical files (e.g., /etc/gitconfig, /root/.ssh/authorized_keys) are not writable by the Gogs process.
5. Monitor for Indicators of Compromise (IOCs):
   • Unexpected creation of repositories containing symbolic links.
   • Sudden modifications to gitconfig or other configuration files.
   • Outbound connections from the Gogs host to unknown IPs shortly after a repository push.
6. Apply Temporary Work‑arounds: If feasible, disable the PutContents API entirely or restrict it to authenticated, role‑based accounts.
7. Plan for Patch Deployment: Track the upcoming Gogs image releases (tagged latest and next‑latest) that incorporate the fix. Prepare automated roll‑out pipelines to minimise exposure time.

Real‑World Impact

Enterprises that rely on Gogs for internal code hosting are facing a race against time. A successful exploit can give attackers a foothold inside the development environment, a prime target for supply‑chain attacks. For example, a compromised CI/CD runner could inject malicious binaries into production releases, affecting downstream customers and eroding brand trust.

Small‑to‑medium businesses that expose Gogs publicly without proper hardening are especially vulnerable. The low barrier to exploitation—no authentication required—means that automated scanners can discover and weaponise vulnerable instances at scale.

Expert Opinion

From a strategic standpoint, CVE-2025-8110 underscores a broader trend: the convergence of source‑code management and runtime orchestration creates a high‑value attack surface. As organisations adopt “GitOps” practices, the line between code repository and production environment blurs, making vulnerabilities like this far more dangerous.

My recommendation for the industry is two‑fold:

1. Shift‑left security: Integrate static analysis and policy enforcement directly into the Git platform. Prevent the creation of dangerous symlinks through repository‑level hooks.
2. Zero‑trust networking: Assume that any exposed service can be probed. Enforce strict identity‑based access, mutual TLS, and micro‑segmentation for developer tooling.

Until the upstream fix lands, organisations that cannot afford a breach should consider temporarily migrating critical repositories to a hardened alternative (e.g., self‑hosted GitLab with stricter defaults) while keeping Gogs instances isolated.