Gogs Patches Critical Zero-Day RCE Flaw After 90-Day Delay

Key Takeaways

• Gogs 0.14.3 fixes an argument injection flaw affecting all versions through 0.14.2 and 0.15.0+dev
• The vulnerability allowed authenticated users to execute arbitrary code by crafting malicious branch names
• Over 2,300 internet-facing Gogs instances are currently exposed according to Shadowserver

The Vulnerability

Gogs, the open-source self-hosted Git service written in Go, has released version 0.14.3 to patch a critical zero-day vulnerability. The flaw allows authenticated attackers to achieve remote code execution on any Gogs server running default configurations.

The argument injection vulnerability (CWE-88) stems from how Gogs handles user-supplied branch names during git rebase operations. An attacker can craft a malicious branch name that injects arbitrary command-line arguments into the underlying Git process. The flaw has not yet received a CVE ID.

All Gogs releases up to and including 0.14.2 and 0.15.0+dev are affected. Attackers who exploit this vulnerability can compromise the server, read any repository including private ones, steal credentials, move laterally across the network, and modify hosted source code.

“The vulnerability effectively allows an authenticated user to escape the expected command constraints by injecting arbitrary flags into the underlying Git process.”

— Jonah Burgess, Security Researcher at Rapid7

Default Configurations Create Easy Targets

The flaw is particularly dangerous because Gogs ships with permissive defaults. Open registration is enabled (DISABLE_REGISTRATION = false), and there is no limit on repository creation (MAX_CREATION_LIMIT = -1). This means unauthenticated attackers can simply create an account, set up a repository, and exploit the vulnerability without any interaction from other users.

Rapid7 researcher Jonah Burgess, who discovered and reported the vulnerability, explained that any registered user who creates a repository automatically becomes its owner. Enabling rebase merging requires just a single toggle in settings, and the entire exploit chain can be executed without help from anyone else.

Shadowserver, the internet security watchdog, currently tracks over 2,300 Gogs instances exposed to the internet. Each one running a vulnerable version with default settings is a potential target.

Three-Month Gap Between Report and Patch

The timeline of this disclosure has drawn criticism. Rapid7 reported the vulnerability to the Gogs maintainers, then went public 10 days before the patch was released, citing a lack of response to multiple status updates. From discovery to patch, approximately 90 days elapsed.

The Gogs maintainers released version 0.14.3 on June 7, 2026, implementing the fix via pull request #8301. They have also requested a CVE ID for the vulnerability.

Immediate Actions for Administrators

Rapid7 recommends all Gogs users upgrade to version 0.14.3 immediately. For administrators who cannot patch right away, the company provided several mitigation measures.

1. Restrict user registration: Set DISABLE_REGISTRATION = true in app.ini. This is the most effective mitigation since the exploit is self-contained within a single user's repository.
2. Restrict repository creation: Set MAX_CREATION_LIMIT = 0 in app.ini, or configure per-user limits via the admin panel. This blocks the easiest attack path but does not prevent exploitation by users with write access to existing repositories.
3. Audit rebase merge settings: 'Rebase before merging' can be disabled per-repo under Settings > Advanced, but this is not an effective defense against users who own or have admin access to a repository, since they can re-enable rebase at will.

Community Response

The vulnerability has sparked intense discussion on Hacker News and the Gogs subreddit. Many self-hosted instance administrators are criticizing the three-month delay between Rapid7's report and the official patch. Several have expressed concern about potential quiet exploitation during that window.

The broader conversation has focused on the dangers of web-based Git interfaces that do not strictly sanitize inputs before shell command execution. Passing untrusted user input directly to system command-line interfaces remains a significant risk pattern.

Context: Why This Matters

Gogs is designed as a lightweight, self-hosted alternative to GitHub Enterprise or GitLab. Organizations choose it for its simplicity and low resource requirements. However, the same simplicity that makes Gogs attractive can create security blind spots when defaults favor convenience over hardening.

This incident underscores a recurring theme in self-hosted software: default configurations often prioritize easy setup over security. Administrators must review and harden settings before exposing any Git service to the internet.

Frequently Asked Questions

Which Gogs versions are affected by this vulnerability?

All Gogs releases up to and including version 0.14.2 and 0.15.0+dev are affected. Version 0.14.3, released on June 7, 2026, contains the fix.

Can unauthenticated attackers exploit this Gogs vulnerability?

Not directly. The vulnerability requires authentication. However, Gogs ships with open registration enabled by default, so attackers can create an account on unprotected instances and then exploit the flaw.

How do I check if my Gogs instance is vulnerable?

Check your Gogs version number. If you are running any version before 0.14.3, you are vulnerable. Also verify your app.ini settings for DISABLE_REGISTRATION and MAX_CREATION_LIMIT.

What can attackers do if they exploit this vulnerability?

Attackers can execute arbitrary code on the server, access all repositories including private ones, steal credentials, move laterally to other systems on the network, and modify any hosted source code.

Is there a CVE number for this Gogs vulnerability?

Not yet. The Gogs maintainers have requested a CVE ID, but it had not been assigned at the time of the patch release.

Source: BleepingComputer