Gogs Has a CVSS 9.4 Zero-Day With No Patch. A Metasploit Module Is Out.

#There is no patch. I want to be clear about that up front.

Gogs is a popular open-source self-hosted Git service. Lightweight, easy to deploy, used by thousands of organizations who want to host their own code repositories instead of paying for GitHub or GitLab.

Rapid7 disclosed a critical vulnerability that lets any authenticated user execute arbitrary code on the server. CVSS 9.4. A public Metasploit exploit module exists. And there is no fix.

The maintainer was notified on March 17, 2026. It's the end of May. Still no patch. The vulnerability is fully documented, the exploit is public, and every Gogs instance on the internet is vulnerable right now.

#How it works (it's embarrassingly simple).

When you create a pull request in Gogs and choose "Rebase before merging," Gogs passes the branch name directly to a git rebase command. No sanitization. No argument separator. Nothing.

So if you create a branch named --exec=touch${IFS}/tmp/pwned, Git treats that as an --exec flag instead of a branch name. It executes whatever command you put after the = sign. On the server. As the Gogs process user.

That's it. Create an account (registration is open by default). Create a repo. Create a branch with a malicious name. Open a pull request. Merge with rebase. Server compromised.

You don't need admin privileges. You don't need another user to interact with your PR. You operate entirely within your own account. On a default Gogs installation with open registration, an unauthenticated attacker can create an account and exploit this in about 60 seconds.

#What an attacker gets.

Once they have code execution on the Gogs server, they can:

• Read every repository on the instance, including other users' private repos. Cross-tenant breach.
• Dump credentials stored in Gogs configuration (database passwords, SMTP credentials, API keys)
• Modify source code in any repository. Plant backdoors. Alter releases. Poison the supply chain.
• Pivot to other systems the Gogs server can reach on the network (databases, internal services, CI/CD pipelines)
• Establish persistence through SSH keys, cron jobs, or modified Gogs binaries

If your Gogs instance is connected to CI/CD (and many are), compromising Gogs means compromising your deployment pipeline. The attacker can modify code, have it automatically built and deployed, and backdoor your production systems.

#Why this matters even if you don't use Gogs.

Two reasons.

First: This is the second self-hosted Git service with a critical vulnerability in the last week. Gitea had CVE-2026-27771 - private container images accessible without authentication for four years. Now Gogs has an unpatched RCE. If you self-host your code repositories, you need to seriously evaluate whether you have the security resources to do it safely.

Self-hosting means you are responsible for patching. You are responsible for monitoring. You are responsible for incident response. When the maintainer doesn't ship a fix for 10 weeks (like Gogs), you're stuck. GitHub and GitLab have dedicated security teams. Gogs has one maintainer who hasn't responded.

Second: The argument injection class of vulnerability is everywhere. Any application that passes user input to a shell command or system binary without proper argument separation is potentially vulnerable. git, ffmpeg, curl, rsync, tar - all of these accept flags that start with --. If user input can become a flag, it can become code execution.

If your business builds software, your developers need to understand this pattern. If your business uses software built by others, you need to know whether those developers understand it.

#What to do right now.

If you run Gogs:

There is no patch. Your options are:

1. Disable the "Rebase before merging" option. This removes the vulnerable code path. In your Gogs configuration, set merge options to only allow regular merge commits. This is the immediate mitigation.

1. Disable open registration. Set DISABLE_REGISTRATION = true in your app.ini. This prevents unauthenticated attackers from creating accounts. Existing users can still exploit it, but the attack surface shrinks significantly.

1. Restrict network access. Your Gogs instance should not be reachable from the public internet without a VPN. If it is, fix that today. The Metasploit module is public. Script kiddies are scanning for this right now.

1. Seriously consider migrating to Gitea or GitLab. Gogs hasn't received a security fix in 10 weeks despite a critical disclosure. Gitea is a maintained fork of Gogs with an active security response team. GitLab has a self-managed edition. Both are better options if the Gogs maintainer isn't responding.

1. If you must stay on Gogs, audit your user list. Remove any accounts you don't recognize. Review recent pull requests for branches with unusual names (especially ones starting with --). Check for signs of compromise.

If you self-host any Git service:

1. Audit your exposure. Is your Git server reachable from the internet? Check Shodan for your IP. If it shows up with a Gogs, Gitea, or GitLab login page, you're exposed.

1. Enable audit logging. Know who's creating repositories, branches, and pull requests. Anomalous activity (new account creating repos and PRs within minutes) is a strong signal.

1. Segment your Git server. It should not have direct access to production databases, deployment pipelines, or sensitive internal services. If it gets compromised, the blast radius should be limited.

#Further reading

• Rapid7 Disclosure - full technical analysis and exploit details
• Gitea - maintained fork of Gogs with active security team
• GitLab Self-Managed - alternative self-hosted Git with enterprise security features
• OWASP Command Injection - the vulnerability class explained
• Shodan - check if your services are internet-exposed