Gogs Zero-Day Exploit Compromises Hundreds of Servers

If you thought open-source self-hosted Git services were a safe haven away from the corporate giants like GitHub or GitLab, the recent breach of Gogs servers might make you reconsider. A zero-day vulnerability in Gogs, identified as CVE-2025-8110, has been weaponized to seize control of over 700 servers worldwide—and this disaster is still unfolding due to an absent patch more than five months after disclosure.

Gogs: Lightweight But Dangerously Exposed

Gogs targets developers seeking a low-cost, lightweight alternative to major Git platforms. It boasts easy installation and minimal resource demands, perfect for organizations wanting to keep their code repositories on-premise. But convenience comes with a price, and Gogs has paid dearly.

The problem centers on a security flaw allowing remote code execution (RCE) through mishandling symbolic links in its PutContents API—a function meant to save data inside repositories. What does that mean? Attackers can craft a repository with symbolic links pointing outside the safe confines of the repo and overwrite sensitive system files, effectively taking over the affected server.

How Did This Happen?

This isn't just a brand-new flaw; it’s an awkward sidestep around a previous fix. Earlier, Gogs patched a similar vulnerability (CVE-2024-55947) meant to prevent writing files outside the repository directory. But the fix ignored symbolic links—a glaring blind spot. Attackers promptly exploited this oversight, making the previous patch almost pointless.

The exploitation steps are brazenly simple:

  • Create a repository.
  • Add a symbolic link inside that repository pointing to a targeted system file.
  • Use the PutContents API to write malicious data to that link.
  • The server follows the link and overwrites critical files, enabling remote code execution.

And the kicker? Anyone with permission to create repositories—which many admins enable by default—can pull this off. It's an embarrassing hole in what should be secure software.

Widespread Exposure and the Attack's Impact

According to Wiz Research, 1,400 Gogs instances are accessible via the internet. Over half—more than 700—have shown signs of compromise. The infected servers share suspicious traits like repositories with nonsensical eight-character names, created in tight timeframes, pointing to coordinated botnet-style attacks rather than random hacking attempts.

Once exploited, the attackers deploy malware using the Supershell framework—an open-source command-and-control platform that sets up reverse SSH shells over web services. This gives the malicious actors remote control over your servers, all while flying under the radar with seemingly legitimate repository actions.

More Than Half a Year Without a Patch

The timeline is frustrating. Researchers first noticed the threat in July 2025 and promptly reported it. Gogs maintainers only acknowledged the issue three months later—October 30—and as of December 10, still no patch has appeared. This kind of radio silence from maintainers invites disaster and reflects poorly on the stewardship of such critical tools.

What You Can—and Must—Do

If you run a Gogs instance exposed to the internet, you better act fast. Waiting for a patch that's nowhere in sight is not a strategy. Instead, implement these practical defenses immediately:

  • Disable Open Registration: Stop strangers from creating repositories. Easier said than enforced in some setups, but critical when your software inherently allows repo creation by default.
  • Limit Internet Accessibility: If you absolutely must expose your Git service, at least put it behind a VPN or an IP allow list. Lock it down tight.
  • Watch for Suspicious Activity: Scan for repositories with random names, especially those created rapidly, and monitor PutContents API usage—anything odd could be a red flag.

Ignoring this would be negligent. If an attacker compromises your server, they could overwrite configs, deploy backdoors, or pivot deeper into your network infrastructure. And that's assuming the attacker stops at just your Gogs server.

Lessons Not Learned

This incident is a prime example of what happens when open-source projects with widespread use falter in their security responses. Overlooking symbolic links in path validation might seem minor, but it’s anything but. It’s a glaring architectural flaw that attackers naturally exploit the moment they spot it.

It's also a cautionary tale about the dangers of relying heavily on self-hosted tools without robust security oversight. The promise of control comes with the burden of constant vigilance. If you’re unwilling or unable to keep your deployments patched and monitored, you might be better off sticking to well-funded platforms with dedicated security teams.

At the end of the day, software vulnerabilities have existed forever. What separates the competent from the careless is rapid response and transparency. The slow turnaround in addressing CVE-2025-8110 is a disturbing indicator—one that's costing hundreds of servers their integrity. If you manage any Gogs instances, start locking things down. The attackers haven't stopped; they never will.

Suggested readings ...