Gogs RCE Flaw Lets Any User Execute Code — No Patch Available

A critical remote code execution vulnerability in Gogs, a popular open-source self-hosted Git service, remains unpatched despite responsible disclosure to maintainers in March 2026. The flaw carries a CVSS score of 9.4 and can be exploited by any authenticated user to execute arbitrary commands on the server.

Rapid7 Labs discovered the argument injection vulnerability (CWE-88) and has released full technical details after multiple attempts to reach the Gogs maintainer went unanswered. A Metasploit module is now available for testing purposes.

Exploitation Details

The vulnerability exists in Gogs' pull request merging functionality. When a repository is configured to use "Rebase before merging," an attacker can create a malicious branch name that injects the --exec flag into the underlying git rebase command.

The attack requires minimal access:

• Authentication: Any registered account (no admin needed)
• Repository access: Attackers can create their own repository
• User interaction: None—entirely self-contained attack

Since Gogs ships with open registration enabled by default and no limit on repository creation, an unauthenticated attacker can simply create an account on any default-configured instance, create a repository, and achieve code execution.

Impact Assessment

Successful exploitation grants attackers shell access with the privileges of the Gogs process. From there, attackers can:

• Access every repository hosted on the instance
• Dump all user credentials and session tokens
• Pivot to other network-accessible systems
• Modify hosted repositories to inject backdoors
• Escalate to full system compromise

On shared hosting environments, this creates a cross-tenant data breach scenario where one malicious user can read private repositories belonging to other users on the same Gogs instance.

Timeline and Maintainer Response

Rapid7 reported the vulnerability to Gogs maintainers on March 17, 2026, and followed up multiple times through May. The maintainer acknowledged receipt on March 28, 2026, but has not provided a patch or further communication. After the standard 90-day disclosure window expired, Rapid7 published the details.

This situation mirrors other unpatched vulnerabilities in open-source tools where single-maintainer projects struggle to respond to security disclosures.

Affected Deployments

Shodan searches identify over 1,100 internet-facing Gogs instances, though internal deployments are likely much higher. Organizations using Gogs for internal code hosting should treat this as a critical priority regardless of internet exposure—any authenticated user represents a potential attacker.

Mitigation Steps

Without a patch, organizations must implement workarounds:

1. Disable user registration: Set DISABLE_REGISTRATION = true in the Gogs configuration
2. Restrict repository creation: Set MAX_CREATION_LIMIT = 0 for untrusted users
3. Audit merge settings: Disable "Rebase before merging" on all repositories
4. Network isolation: Move Gogs instances behind VPN or zero-trust access
5. Consider migration: Evaluate moving to actively maintained alternatives like Gitea or GitLab

Why This Matters

Gogs has historically been a lightweight alternative to GitLab and GitHub Enterprise for organizations wanting self-hosted Git. But single-maintainer open-source projects face well-documented challenges responding to security issues. When maintainers go unresponsive, organizations are left exposed.

This vulnerability demonstrates why security teams should factor maintainer responsiveness into their vendor risk assessments for open-source dependencies. The browser extension security issues we covered recently show similar patterns where supply chain trust assumptions fail.

Organizations running Gogs should implement mitigations immediately and plan migration timelines. The combination of a public exploit module and unresponsive maintainer makes this a high-risk situation.