Executive Summary
CVE-2025-8110 is an actively exploited, unpatched Remote Code Execution (RCE) vulnerability affecting all Gogs versions ≤ 0.13.3. The flaw allows authenticated users to bypass path-traversal protections through a symlink-based file-write bypass, enabling arbitrary file overwrite on the host server and ultimately full system compromise. With no official patch available and exploitation occurring in the wild, all self-hosted Gogs instances should be considered at risk and require immediate mitigation.
The Core Issue: A Symlink Blindspot
This vulnerability is effectively a bypass of a fix for a previous issue (CVE-2024-55947).
Earlier this year, Gogs patched a vulnerability where attackers used “dot-dot” traversal (../) in file paths to escape the repository directory. The maintainers added validation to block malicious file names. However, CVE-2025-8110 sidesteps this check entirely.
Instead of manipulating the filename, attackers manipulate the file type.
How the Bypass Works
The flaw lies in the discrepancy between how Gogs validates a path and how the Operating System (OS) writes to it.
- Validation: The Gogs API checks the requested filename (e.g.,
config). It sees a valid name inside the repository and approves it. - Execution: When the API writes data to that filename, it does not check if the file is a symbolic link.
- The Jump: If the file is a symlink pointing outside the repository (e.g., to
/home/git/.ssh), the OS follows the link and overwrites the external target.
The Attack Chain
The exploitation requires low-privilege access (often available via default “Open Registration”) and follows a simple four-step process:
- Preparation: The attacker creates a standard Git repository.
- Injection: The attacker commits a symbolic link to the repository. This link points to a sensitive system file (e.g.,
.git/config or authorized_keys). - Trigger: The attacker uses the
PutContentsAPI to write malicious payloads to the symlink. Gogs approves the write because the filename looks safe. - RCE: The payload overwrites the target file. By targeting the repository’s
.git/config, attackers inject acore.sshCommand, forcing the server to execute their code during the next Git operation.
Note on Scope: This affects Gogs versions ≤ 0.13.3. Since no patch exists, all current versions are potentially vulnerable.
Signs of Compromise
Recent “smash-and-grab” campaigns suggest automated exploitation. Check your instance for:
- Suspicious Repositories: New repos created with random, 8-character alphanumeric names.
- Unknown Processes: Unexpected shell commands or outbound network connections from the Gogs service user.
- Modified Configs: unauthorized changes to
.git/configfiles within repositories or system-level SSH keys.
Immediate Mitigation Strategies
Since you cannot upgrade to a patched version yet, you must reduce the attack surface.
1. Disable Open Registration
This is the most effective immediate stop-gap. If attackers cannot create an account, they cannot create the repository needed to launch the exploit.
2. Network Isolation
Gogs should never be exposed directly to the public internet.
- Place the instance behind a VPN or a strict firewall allow-list.
- If public access is required, place it behind an authentication proxy to prevent unauthorized API access.
Runtime Protection with Upwind
When software remains unpatched, runtime visibility is your last line of defense. Upwind helps secure vulnerable Gogs instances by:
- Mapping Vulnerable Assets: Instantly identifying all running Gogs instances and mapping their exposure level.
- Detecting Exploitation Attempts: Monitoring for the specific behavioral patterns of the symlink exploit (e.g., unexpected file writes outside the repo path).
- Identifying Post-Exploitation Activity: Flagging the execution of suspicious child processes and communication with known C2 IPs.
Protect your infrastructure even when the code is vulnerable. For support or to check your exposure, contact [email protected].
