A critical argument injection vulnerability in Gogs — the open-source self-hosted Git service — carries a CVSS score of 9.4, allows any authenticated user to execute arbitrary code on the server, has been unaddressed by maintainers since a responsible disclosure notification in March 2026, and now has a fully functional Rapid7 Metasploit module automating the exploit chain.
Gogs Argument Injection Zero-Day: Any Authenticated User Can Execute Code on the Server
The flaw allows an attacker to craft a pull request with a branch name that injects the --exec flag into Gogs’ git rebase operations. When the rebase runs, arbitrary commands execute under the Gogs server process account. Because Gogs enables open registration by default, any internet-accessible Gogs instance can be targeted by a newly created account — the attack does not require a pre-existing relationship or elevated privileges within the Gogs installation.
Rapid7’s Metasploit Module Automates the Full Gogs Zero-Day Exploit Chain
Rapid7, which discovered the vulnerability and performed the responsible disclosure, has released a Metasploit module that automates the complete exploit sequence for the Gogs zero-day. The module’s availability means that organizations with automated vulnerability scanning and exploitation infrastructure can now target unpatched Gogs instances at scale with minimal manual effort. Any Gogs server accessible from the internet with open registration enabled faces a substantially elevated risk from the moment the Metasploit module became publicly available.
This Is the Second Gogs Zero-Day in Six Months: Maintainer Non-Response Is a Compounding Risk
Rapid7’s disclosure follows CVE-2025-8110, a zero-day in Gogs disclosed in December 2025. In both cases, the Gogs maintainer has not responded to security reports. For CVE-2025-8110, that silence persisted through the December 2025 disclosure; for the current vulnerability, the maintainers were notified in mid-March 2026 and have not issued a patch or public acknowledgment. The pattern of non-response to critical security reports means organizations relying on Gogs face ongoing exposure without a predictable remediation timeline from the upstream project.
Recommended Actions for Gogs Administrators Until a Patch Exists
With no patch available, organizations running Gogs should take immediate mitigating steps. Disabling open registration — so that only pre-approved accounts can create pull requests — removes the primary exploit path for attackers without existing accounts. Organizations that cannot restrict registration should consider placing Gogs behind a network access control layer that restricts who can reach the service. Migrating to an actively maintained Git hosting alternative may be necessary for organizations with high security requirements and no tolerance for an indefinite unpatched exposure window.
