A zero-day vulnerability in Gogs, a widely used self-hosted Git service, tracked as CVE-2025-8110, is being actively exploited in the wild, enabling authenticated attackers to overwrite files outside of repositories and achieve remote code execution on vulnerable servers; more than 700 Internet-facing instances appear compromised and no official patch is yet available, prompting emergency mitigation guidance for administrators.
Sources: Hacker News, Run Zero
Key Takeaways
– Active exploitation ongoing: Attackers are abusing the vulnerability in real conditions, not just in lab settings.
– Widespread exposure: Hundreds of publicly accessible Gogs servers have been compromised, with many more potentially vulnerable.
– No fix yet: A patch is still pending, increasing the urgency for defensive steps and configuration hardening by system owners.
In-Depth
A newly discovered security weakness in Gogs — the open-source, self-hosted Git hosting platform — has escalated from theoretical concern to real-world crisis within a matter of days. The vulnerability, designated CVE-2025-8110, involves improper handling of symbolic links in Gogs’ PutContents API, a component used when users push or update content in a repository. Because the flaw allows authenticated users to create or commit a symbolic link that points to an arbitrary location outside of the normal repository structure, an attacker with valid repository creation permissions can cause the server to overwrite arbitrary files on the underlying system. This file overwrite can be marshalled into a fully functional remote code execution (RCE) exploit, giving unauthorized code the same privileges as the Gogs server process. The issue appears to be a bypass of a prior fix (for CVE-2024-55947), which attempted to close a similar remote code execution hole but failed to properly address the interaction with symbolic links.
According to independent threat researchers and security advisories, the vulnerability is not confined to theoretical proof-of-concepts — it is being actively and repeatedly exploited on internet-exposed installations. One security firm’s telemetry identified upwards of approximately 1,400 Gogs servers visible on the public internet, of which more than 700 have shown evidence of compromise. The compromise signatures include the appearance of repositories with random eight-character names, suggestive of automated tooling being used post-exploitation. Researchers first encountered the flaw while responding to a malware incident on a customer’s workload earlier in 2025, and the exploitation appears to have been ongoing for months before public disclosure.
Compounding the severity is the absence of an official patch at the moment of reporting. Unlike many open-source projects that can rapidly issue emergency releases, the Gogs maintainers have not yet made a fixed version available, leaving operators exposed. In the interim, security advice centers around mitigation and exposure reduction: disabling open user registration (which is enabled by default in many deployments), placing the service behind a private network or VPN, and restricting public access via IP allow-listing. Administrators are also urged to scan internal networks for susceptible Gogs instances and to check logs or repository listings for indicators of compromise. Given the way the vulnerability operates, even authenticated but low-privilege users — such as those signing up for accounts on publicly facing servers — can trigger the exploit, underscoring the importance of minimizing unnecessary access and public visibility.
From a broader security lens, this situation highlights the risks inherent in self-hosted software services that combine web APIs with file system operations — especially when symbolic link handling is involved. It also illustrates how a fix for one serious remote code execution flaw can inadvertently leave a one-day bypass if the underlying logic isn’t thoroughly re-examined. Until a patch is issued and widely deployed, defenders must assume that any Gogs instance exposed to the internet is a potential entry point for compromise and act accordingly to contain the threat vector.