Unpatched Gogs Zero-Day Enables Remote Code Execution on Git Servers

An unpatched zero-day vulnerability in the Gogs self-hosted Git service allows authenticated attackers to execute remote code on Internet-facing instances. The flaw, discovered by Rapid7 researcher Jonah Burgess, affects the latest release versions and remains unpatched despite responsible disclosure in March. Consequently, organizations running Gogs with default configurations face immediate risk of complete server compromise.

What Happened: Unpatched Gogs Zero-Day Allows Remote Code Execution

Gogs is a popular open-source, self-hosted Git service written in Go. It serves as an alternative to GitHub Enterprise and GitLab for organizations that want full control over their source code repositories. Moreover, it is frequently exposed to the Internet to enable remote collaboration among distributed development teams.

On May 28, 2026, Rapid7 disclosed a critical argument injection vulnerability that enables authenticated remote code execution (RCE) on affected Gogs servers. The flaw has not yet received a CVE identifier. However, it affects the latest versions including Gogs 0.14.2 and 0.15.0+dev. Furthermore, the vulnerability can be exploited by any registered user without administrative privileges.

Perhaps most concerning, default Gogs installations ship with open registration enabled and no limit on repository creation. Therefore, an unauthenticated attacker can create an account, become a repository owner, and trigger the exploit chain without interaction from any other user. The researcher reported the flaw to Gogs maintainers on March 17, but no patch has been released despite acknowledgment on March 28.

Technical Details of the Gogs Vulnerability

The vulnerability stems from an argument injection flaw in the Merge() code path that was never patched despite similar issues being fixed in prior years. Attackers exploit the flaw by submitting a pull request that uses a malicious branch name to inject the --exec flag into git rebase during the “Rebase before merging” merge operation.

Successful exploitation allows attackers to execute arbitrary code remotely as the Gogs server process user. Moreover, the impact extends far beyond a single repository. A compromised attacker can read every repository on the instance including other users’ private repos. In addition, they can dump credentials such as password hashes, API tokens, SSH keys, and two-factor authentication secrets. They can also pivot to other network-accessible systems and modify any hosted repository’s code.

The attack prerequisites are minimal:

• A Gogs instance running a vulnerable version (0.14.2 or 0.15.0+dev)
• Open registration enabled or existing valid user credentials
• The “Rebase before merging” option enabled in repository settings

Internet security watchdog Shadowserver currently tracks over 2,400 Gogs servers exposed online. Most of these instances are located in Asia and Europe. Additionally, Shodan has identified just over 1,000 IP addresses with a Gogs fingerprint. Many instances are configured with open registration enabled by default, creating a substantial attack surface.

This vulnerability is not the first RCE flaw in Gogs. In early December 2025, another Gogs RCE vulnerability (CVE-2025-8110) was exploited in zero-day attacks to compromise hundreds of servers. CISA added that flaw to its Known Exploited Vulnerabilities catalog and ordered federal agencies to secure their systems. Therefore, the pattern of critical RCE vulnerabilities in Gogs suggests organizations should treat this software with elevated caution.

Business and Operational Impact

The exploitation of this unpatched Gogs zero-day poses severe consequences for development teams and the organizations they serve. Source code repositories contain some of the most sensitive intellectual property in modern enterprises. Consequently, a successful attack can expose proprietary algorithms, internal APIs, and authentication mechanisms.

Real-world consequences include:

• Source code theft: Attackers gain access to every repository on the instance including private codebases
• Credential exposure: Password hashes, API tokens, SSH keys, and 2FA secrets can be extracted from the database
• Supply chain compromise: Attackers can modify source code to inject backdoors into software builds and CI/CD pipelines
• Lateral movement: Compromised SSH keys and service credentials enable further network penetration
• Regulatory exposure: Loss of source code and development secrets may trigger breach notification requirements under GDPR, CCPA, and industry-specific frameworks

For managed service providers and development agencies hosting Gogs for multiple clients, a single compromise could cascade across tenant boundaries. Moreover, the trust relationships embedded in source code repositories make this an attractive target for advanced persistent threat actors seeking long-term access.

Mitigation and Recommendations

Immediate Actions for Defenders

1. Disable open registration on Internet-facing Gogs instances immediately. Set DISABLE_REGISTRATION = true in the application configuration.
2. Restrict repository creation to trusted users only. Set MAX_CREATION_LIMIT to a low value appropriate for your organization.
3. Disable the “Rebase before merging” merge strategy for all repositories until a patch is available.
4. Review access logs for unusual account registrations, repository creations, and pull request activity from unfamiliar IP addresses.
5. Audit for unauthorized code changes in recent commits and pull request merges.
6. Rotate all API tokens, SSH keys, and service credentials stored in or associated with the Gogs instance.

Long-Term Hardening Measures

• Consider migrating to actively maintained alternatives such as GitLab or Gitea if Gogs patching cadence remains unreliable
• Place Gogs behind a VPN or reverse proxy with strong authentication rather than exposing it directly to the Internet
• Implement network segmentation between source code hosting and production infrastructure
• Enable comprehensive audit logging for authentication, repository access, and administrative actions
• Subscribe to security advisories from Rapid7, Shadowserver, and CISA for early warning of exploitation
• Conduct regular vulnerability scans of externally facing development infrastructure

Bottom line: This unpatched Gogs zero-day allows authenticated attackers to achieve remote code execution and complete server compromise. With no patch available after more than two months of responsible disclosure, immediate configuration changes and access restrictions are essential for all organizations running Internet-facing Gogs instances.

Incident Summary

CVE ID / Incident:	Unpatched zero-day (no CVE assigned yet) in Gogs
Affected Systems:	Gogs 0.14.2 and 0.15.0+dev; self-hosted Git service instances
Disclosure Date:	March 17, 2026 (reported); May 28, 2026 (publicly disclosed)
Patch Status:	No patch available as of May 29, 2026
Severity:	Critical — authenticated remote code execution
Exposed Instances:	Over 2,400 Internet-facing instances (Shadowserver Foundation)

References

1. Sergiu Gatlan, BleepingComputer, “New Gogs zero-day flaw lets hackers get remote code execution,” May 28, 2026, https://www.bleepingcomputer.com/news/security/new-gogs-zero-day-flaw-lets-hackers-get-remote-code-execution/ (accessed May 29, 2026).
2. Jonah Burgess, Rapid7, “Authenticated RCE via Argument Injection in Gogs (Unfixed),” May 28, 2026, https://www.rapid7.com/blog/post/ve-authenticated-rce-via-argument-injection-gogs-unfixed/ (accessed May 29, 2026).
3. The Shadowserver Foundation, “Internet-Exposed Gogs Servers,” https://dashboard.shadowserver.org/statistics/iot-devices/time-series/ (accessed May 29, 2026).
4. CISA, “Known Exploited Vulnerabilities Catalog — CVE-2025-8110,” January 12, 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (accessed May 29, 2026).