CISA KEV Deadline Hits Today for Unpatched Gogs Zero-Day

Federal agencies face a compliance deadline today for a Gogs vulnerability that has no official patch. CVE-2025-8110, a path traversal flaw enabling remote code execution, was added to CISA's Known Exploited Vulnerabilities catalog with a February 2, 2026 remediation deadline. The problem: Gogs maintainers haven't released a fixed version yet. This isn't the first time CISA has added vulnerabilities to the KEV catalog that create compliance headaches for organizations.

Wiz Research discovered the vulnerability while investigating malware on a customer workload. They found attackers had been exploiting CVE-2025-8110 as a zero-day since at least November 2025, compromising over 700 internet-facing Gogs instances before anyone knew the flaw existed.

What Is Gogs?

Gogs is a lightweight, self-hosted Git service written in Go. Organizations use it as a private alternative to GitHub or GitLab when they want to keep source code on their own infrastructure. Its small footprint and easy deployment made it popular among developers who wanted Git hosting without the overhead of larger platforms.

That simplicity comes with a tradeoff. The project is maintained by a small team, and security response times can lag behind enterprise-grade alternatives. This creates a window of exposure when critical vulnerabilities emerge.

How the Attack Works

CVE-2025-8110 bypasses protections implemented for a previous RCE vulnerability (CVE-2024-55947) through a path traversal weakness in the PutContents API. An authenticated attacker creates a symbolic link inside a repository that points to a file outside the repo's directory structure—something like /etc/passwd or, more usefully, .git/config.

When the attacker sends a request through the API to write to that symlink, Gogs follows it and overwrites the target file. By overwriting .git/config with malicious content, attackers can configure Git hooks that execute arbitrary commands the next time someone interacts with the repository.

The attack chain requires authentication, but Gogs often runs with open registration enabled by default. An attacker can simply create an account, set up a malicious repository, and achieve code execution within minutes.

Wiz observed attackers using this technique to deploy cryptocurrency miners, backdoors, and data exfiltration tools across compromised instances.

Scope and Exposure

Censys data shows over 1,600 internet-exposed Gogs servers globally. China hosts the largest share with 991 instances, followed by the United States (146), Germany (98), Hong Kong (56), and Russia (49).

Wiz confirmed that attackers had already compromised more than 700 of these systems before the vulnerability was publicly disclosed. The second wave of attacks began November 1, 2025, suggesting multiple threat actors became aware of the flaw around the same time.

Organizations running Gogs versions up to 0.13.3 are vulnerable. That includes virtually every production deployment, since 0.13.3 was the latest release when attacks began.

The Patch Situation

Here's where this gets awkward. CISA added CVE-2025-8110 to the KEV catalog on January 30, 2026, giving federal agencies until February 2 to remediate. But there's no fixed Gogs release to deploy.

Code changes addressing the vulnerability have been submitted to Gogs' main development branch. A maintainer indicated that once new container images are built, both the "latest" and "next-latest" releases will include the fix. No timeline was provided.

Federal agencies—and anyone else running internet-exposed Gogs—face an uncomfortable choice: run an unpatched system, deploy an untested development build, or take the service offline entirely.

Defensive Measures

Without an official patch, Wiz and security researchers recommend several workarounds:

1. Disable open registration - Don't let anonymous users create accounts on your Gogs instance
2. Restrict network access - Put Gogs behind a VPN or IP allowlist so only authorized users can reach it
3. Monitor API activity - Watch for suspicious patterns in PutContents API calls, especially those referencing paths outside repository directories
4. Check for indicators of compromise - Look for repositories with random 8-character names, unexpected symbolic links, or modified .git/config files

Organizations that have been running internet-exposed Gogs instances should assume compromise and investigate accordingly. The flaw was exploited for months before disclosure.

Why This Matters

Self-hosted Git servers hold source code, credentials, deployment configurations, and other sensitive data that attackers prize. A compromised Gogs instance doesn't just give attackers access to code—it provides a foothold for supply chain attacks. We've seen this pattern with malicious VSCode extensions and other developer tool compromises where attackers target the software supply chain.

An attacker who controls a Git server can inject malicious code into builds, steal credentials stored in repositories, or pivot deeper into internal networks. The organizations running Gogs tend to be smaller shops without dedicated security teams, making them attractive targets.

This incident also highlights the risks of relying on community-maintained projects for security-critical infrastructure. When a vulnerability emerges, there's no SLA guaranteeing a patch within a specific timeframe. CISA can set all the deadlines it wants, but if maintainers can't ship a fix, organizations are left scrambling. Compare this to Ivanti's EPMM zero-days, where a commercial vendor at least provided mitigation scripts within days of disclosure.

For those evaluating self-hosted Git options, this is a reminder to consider security response capabilities alongside features. A project with fewer maintainers may move slowly when attackers don't.

Frequently Asked Questions

Is my Gogs instance affected? If you're running any version up to and including 0.13.3 with the web interface accessible from untrusted networks, yes. The vulnerability requires authentication, but default Gogs configurations allow open user registration, making it trivially exploitable.

What should I do if I can't take Gogs offline? Disable user registration immediately, restrict network access to known IP addresses or VPN users, and implement monitoring for suspicious API activity. Consider whether your threat model can tolerate running unpatched software—for many organizations, the answer should be no.