We’re joined today by Rupert Marais, our in-house security specialist, to dissect a critical zero-day vulnerability currently under active and widespread exploitation. The flaw, found in the popular self-hosted Git service Gogs, stems from an incomplete patch for a previous issue, allowing attackers to achieve remote code execution with alarming ease. We’ll explore the anatomy of this “smash-and-grab” campaign, which has already compromised over half of the exposed instances detected, the complex decisions behind its public disclosure, and the crucial lessons this incident offers for both open-source maintainers and the security teams defending their environments.
The research highlights how CVE-2025-8110 bypasses a previous patch by abusing symbolic links. Can you walk us through the step-by-step attack chain an actor would use, from committing a symlink to ultimately achieving remote code execution on a vulnerable Gogs server?
Absolutely, and the frightening part is its simplicity. An attacker doesn’t need sophisticated tools for this. It starts with finding a Gogs server with open registration enabled, which is the default setting. They simply create a new account, just like any legitimate user would. Then, they create a standard git repository. The magic happens in the next step: using standard git commands, they commit a symbolic link—a symlink—to that repository. This link is crafted to point to a sensitive file or location outside of the repository’s intended directory, for instance, a configuration file or a directory where the web server executes scripts. Finally, the attacker uses the Gogs PutContents API to write a malicious file, but they target the symlink they just created. The server’s validation check, which was put in place to fix the previous vulnerability, only looks at the path name and sees that it’s within the repository. It completely fails to check where that symlink is actually pointing, effectively rendering the patch useless. The server follows the link and writes the attacker’s file to the sensitive location, leading directly to remote code execution.
You described the exploitation as an automated “smash-and-grab” campaign with an over 50% compromise rate. What specific forensic evidence, like the 8-character repo names, led you to suspect a single actor, and what does finding the Supershell C2 framework suggest about their potential origin?
When we started digging into the compromised instances, a distinct pattern emerged that was too consistent to be a coincidence. On every single infected server we analyzed, we found newly created repositories with randomly generated 8-character names. What’s more, when we cross-referenced the creation times, they were all clustered within the same short window, starting around July 10th. This uniformity screams automation. It strongly suggests a single actor, or at least a single group, using the same custom tooling to scan for vulnerable servers and exploit them en masse. The “smash-and-grab” description really fits because it’s not a targeted, stealthy attack; it’s a wide net designed to compromise as many machines as possible, as quickly as possible. The discovery of Supershell on one of these systems adds another layer. Supershell is a known open-source command-and-control framework, and while its use isn’t definitive proof, it has been previously associated with threat actors linked to China. It’s a significant clue, but we have to be careful not to jump to conclusions on attribution based on one piece of evidence.
The disclosure timeline notes you reported the flaw in July but went public in December without a patch after seeing a second attack wave. Could you elaborate on the decision-making process behind this, and the challenges of balancing responsible disclosure with protecting potential victims?
This was an incredibly difficult situation and it highlights a classic dilemma in cybersecurity. We confirmed active exploitation on July 10th and reported it to the Gogs maintainers within two days, following standard responsible disclosure practices. The goal is always to work with maintainers to get a patch out before attackers can cause widespread damage. However, we waited, and for over three months, the vulnerability remained unacknowledged. You’re in a bind because going public too early could tip off more attackers, but staying silent leaves existing and future victims completely in the dark. We held off, hoping for a coordinated remediation. Then, on November 1st, we saw a renewed, second wave of attacks. At that point, the calculus changed. The vulnerability was clearly being exploited at scale, and with no patch in sight, the potential for harm was growing every day. We decided that the risk of continued silence outweighed the risk of broader disclosure. Publishing our findings became the only viable path to warn the thousands of organizations running Gogs and give them the information they needed to protect themselves.
For vulnerable organizations, you recommend disabling open registration. Beyond this, can you provide a detailed, step-by-step guide on how a security team could proactively hunt for indicators of compromise, such as unexpected PutContents API usage, within their environment?
Disabling open registration is absolutely the first and most critical step if you don’t need it. That closes the front door for this specific attack vector. For proactive threat hunting, your team should immediately focus on the Gogs server logs. First, look for the creation of repositories with those distinct, random 8-character names. If you see those, especially associated with a recently created user account, that’s a massive red flag and you should assume compromise. Second, audit your API usage logs specifically for the PutContents API. An attacker using this exploit will generate calls to this endpoint that look out of place. You’re looking for any unexpected or high-volume usage of this API call, as it’s the core mechanism for writing the malicious file. Finally, perform file integrity monitoring on your server. Scan for any recently created or modified files in sensitive system directories that shouldn’t be touched by the Gogs application. If you find unexpected scripts or configuration changes, it’s a strong indicator that an attacker has successfully used the symlink trick to write files outside of the git repository’s boundaries.
This vulnerability originated from an incomplete fix for a previous issue. Based on your experience, how frequently do you see new exploits arise from failed patches in open-source projects? What key lessons can both maintainers and security teams learn from this incident about validating fixes?
Unfortunately, seeing new exploits arise from incomplete patches is more common than we’d like, especially in open-source projects where maintainers are often volunteers or small teams with limited resources. It’s a classic case of fixing the symptom but not the underlying disease. The original patch for CVE-2024-55947 correctly identified that path traversal was the problem, but it only blocked the most direct route. It failed to account for an attacker’s creativity in using something like a symbolic link to achieve the same goal. The key lesson for maintainers is that security validation must be adversarial. You can’t just check if the specific reported attack is blocked; you have to think about all the ways an attacker could bypass your logic. For security teams, the lesson is one of healthy skepticism. Never assume a patch makes you completely safe. This incident is a powerful reminder that you must continue to monitor systems for anomalous behavior even after they are “patched.” A defense-in-depth strategy, including logging, monitoring, and proactive threat hunting, is your best defense against the inevitable reality that not all fixes are final.
