Why Gogs Keeps Getting Hacked: The Symlink Problem That Won't Die
Despite a previous patch for a path traversal vulnerability (CVE-2024-55947), Gogs continues to face exploitation. We are currently observing active exploitation of a recently discovered Gogs zero-day flaw, CVE-2025-8110, which bypasses a previous fix. This isn't just about one patch; it points to a fundamental challenge in how web applications, especially open-source ones, manage file system operations, a challenge acutely highlighted by this Gogs zero-day flaw.
Discussions within the Gogs community reveal significant concern. Reports indicate that over 700 of approximately 1,400 publicly exposed Gogs instances are already compromised, and the fact that this bypasses a prior patch (CVE-2024-55947) intensifies concerns. Discussions on security forums and community channels frequently highlight the default 'open registration' setting as a significant enabler. This scenario is a common one: a seemingly minor configuration choice becomes the initial access vector for widespread compromise.
The Incident: A Gogs Zero-Day Flaw Bypasses the Last Fix
A recent discovery, identified by Wiz Research in July 2025, reveals a critical Gogs zero-day flaw (CVE-2025-8110) in Gogs, the self-hosted Git service, enabling authenticated attackers to achieve remote code execution (RCE). The root cause is improper symbolic link handling within the PutContents API.
Since its discovery in July 2025, this Gogs zero-day flaw has been actively exploited. Over 700 of approximately 1,400 publicly exposed Gogs instances are reportedly compromised. Threat actors are using the sophisticated Supershell command-and-control framework to maintain persistent access, indicating a strategic objective beyond immediate impact.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-8110 to its Known Exploited Vulnerabilities (KEV) catalog on January 12, 2026, mandating federal agencies to apply mitigations by February 2, 2026. However, despite acknowledgment from Gogs maintainers in October 2025, an official patch remains unavailable. This delay leaves many users vulnerable.
How a Symlink Trick Leads to RCE
The attack chain here represents a sophisticated abuse of established file system logic.
The central problem lies in how Gogs' PutContents API processes file paths, especially those involving symbolic links, which is the core mechanism of this Gogs zero-day flaw. A symlink acts as a pointer to another file or directory. If an application fails to properly validate or resolve these links before executing file operations, an attacker can manipulate it into writing to unintended locations.
The sequence of events typically begins with Authentication: The attacker first requires authenticated access to a Gogs instance. The default 'open registration' setting often provides this initial access, allowing any registrant to become an authenticated attacker.
Next, the attacker proceeds with Crafting the Symlink: They use the PutContents API to create a symbolic link. This symlink is crafted to point outside the repository's intended directory structure, targeting a sensitive system file or directory, such as /etc/passwd or a web server configuration file.
This then leads to Bypassing the Previous Fix: The previous fix (CVE-2024-55947) likely addressed specific path traversal patterns, perhaps through sanitization of ../ sequences. However, symlinks function as legitimate file system features. In this case, the PutContents API failed to properly resolve the symlink's true destination, allowing it to bypass earlier input validation.
With the symlink established, the attacker achieves Arbitrary File Write: The attacker uses the PutContents API again, directing content to the symlink. Because the application follows the symlink without adequate checks, the content is written to the target file or directory on the system.
Finally, this leads to Remote Code Execution: Arbitrary file write capabilities frequently lead to RCE. An attacker can overwrite web server configurations to inject malicious scripts, modify cron jobs, or deploy a web shell into a publicly accessible directory, thereby gaining full system control.
This incident highlights the ongoing challenge of securely handling symbolic links, a core aspect of the Gogs zero-day flaw. Git itself relies on symlinks, making it impractical to simply disable them. Effectively managing the interplay between user-controlled paths, file system operations, and trust boundaries requires meticulous implementation to prevent logic flaws or race conditions.
The Real Impact: Beyond Just a Server
Immediate consequences include remote code execution (RCE) on a Gogs instance, which translates to full system compromise. This Gogs zero-day flaw means organizations using Gogs face exposure of their code repositories, potentially sensitive project data, and any stored credentials. The use of the sophisticated Supershell C2 framework further indicates attackers are establishing persistent footholds, complicating detection and eradication efforts.
The problem isn't just about one server; it impacts the entire open-source community. Many smaller teams use Gogs, often without dedicated security personnel. When a critical vulnerability appears with no quick fix, these users are left scrambling for workarounds, relying on temporary mitigations or community-driven efforts. This situation highlights the operational strain on open-source projects with limited maintainer resources, where security fixes can lag significantly behind active exploitation.
What You Can Do Right Now
Given the absence of an official patch, Gogs administrators must implement immediate, proactive measures to mitigate the risk posed by CVE-2025-8110, this critical Gogs zero-day flaw. The initial priority is to address the primary access vector: disable open registration immediately.
This critical step directly eliminates the ability for unauthenticated users to create accounts, thereby preventing attackers from gaining the necessary authenticated access to exploit the PutContents API.
Beyond user access, network segmentation is paramount. Administrators should restrict network access to their Gogs instance.
Ideally, remove it from direct exposure to the public internet, placing it behind a VPN, an internal network, or a strictly configured firewall that permits access only from explicitly trusted IP ranges. This significantly reduces the external attack surface, limiting potential entry points for exploitation of the Gogs zero-day flaw.
Proactive detection is also essential. Organizations should monitor for known C2 indicators of compromise, specifically looking for unusual outbound network connections, suspicious processes, or unexpected file modifications that align with the Supershell framework or other observed threat actor activity. Early detection of ongoing compromise is crucial for containment and response.
In the absence of an official vendor patch, the community often develops temporary solutions. Therefore, it is necessary to evaluate and apply community mitigations with extreme caution.
While monitoring Gogs community forums and GitHub for unofficial patches or detailed workarounds is advisable, any such solution must undergo thorough review and rigorous testing in a non-production environment before deployment. This prevents the inadvertent introduction of new vulnerabilities or system instability, especially given the nature of this Gogs zero-day flaw.
To ensure resilience against successful attacks, **ensure regular, verified backups** of your Gogs data and the underlying system. These backups represent the final line of defense, providing a reliable mechanism for recovery in the event of a successful compromise and data integrity loss.
System hardening through the principle of least privilege is another critical defense against the Gogs zero-day flaw. **Implement the principle of least privilege** for the Gogs service account. If the service account does not require write access to sensitive system directories such as /etc/, those permissions should be explicitly revoked. This limits the potential impact and scope of damage should an arbitrary file write vulnerability be successfully exploited.
Finally, for organizations where Gogs' security posture and its patch cycle consistently present operational concerns, a strategic re-evaluation is warranted. It may be prudent to **evaluate alternative self-hosted Git solutions** that are supported by more established security teams and demonstrate a history of faster, more consistent response times to critical vulnerabilities, such as this Gogs zero-day flaw. This long-term consideration addresses the systemic challenges highlighted by recurring issues like CVE-2025-8110.
The recurring Gogs symlink vulnerability, specifically this Gogs zero-day flaw, isn't an isolated incident; it reflects a systemic challenge in handling file system primitives within web applications, especially in open-source projects with constrained resources. Moving forward, we should aim to shift from reactive patching to proactive security design and provide better support for these critical infrastructure components. The cycle of "fix-bypass-exploit" needs to be broken.
