On May 29, 2026, Rapid7 released a technical analysis of a zero-day vulnerability in Gogs, the open-source self-hosted Git service, assigning it a critical CVSS score of 9.4. The flaw allows authenticated attackers to achieve remote code execution (RCE) via argument injection in the git rebase --exec command, resulting in total compromise of the affected server. The situation carries significant political weight: project maintainers were notified in mid-March 2026 and acknowledged receipt of the report, yet no fix had been released at the time of publication.
- CVSS 9.4, Critical Severity: Argument injection in
git rebase --execduring "Rebase before merging" operations allows arbitrary command execution with the privileges of the Gogs server process. - Default configurations maximize the attack surface: Open registration is enabled by default, there are no repository limits, and a single toggle activates rebase merging.
- This marks the second critical zero-day in Gogs within six months, following the CVE-2025-8110 flaw disclosed by Wiz in December 2025.
- Rapid7 has released a Metasploit module and indicators of compromise (IoCs), making the exploit replicable for any threat actor.
The Attack Mechanism: When Branch Names Become Code
The vulnerability lies in how Gogs processes branch names during merge operations. When an instance administrator enables the "Rebase before merging" option, the server invokes git rebase using arguments derived from the source branch name of a pull request. Gogs fails to sanitize these inputs. An attacker can inject the --exec flag into a branch name, which git rebase interprets as an instruction to execute a shell command after every replayed commit.
The source explicitly describes the chain: the --exec flag "tells Gogs to run a shell command after replaying each commit," executing within the context of the server process. This is not a vulnerability in Git itself; the git rebase --exec tool is a legitimate, documented feature. The flaw exists in the Gogs wrapper that exposes this feature to uncontrolled external input.
Default settings amplify the risk beyond the bug's existence. According to the source, Gogs "ships with open registration enabled by default and no limit on repository creation." An unauthenticated attacker can create an account, initialize a repository, enable rebase merging via the web interface, and exploit the vulnerability "without user interaction, as the attacker operates entirely within their own account and repository." The attack path is entirely self-contained and easily automated.
"The result is arbitrary command execution as the Gogs server process user, giving the attacker the ability to compromise the server, read every repository on the instance (including other users' private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), pivot to other network-accessible systems, and modify any hosted repository's code" — Rapid7, as reported by SecurityWeek
The Impact: Total Compromise, Not Partial Leakage
The result is not a limited data leak or a local privilege escalation. The source lists a range of documented consequences: reading every repository on the instance (including private ones); dumping credentials including password hashes, API tokens, SSH keys, and 2FA secrets; pivoting to other network-accessible systems; and arbitrary modification of hosted code. With the privileges of the server process, the attacker gains access to the filesystem and Gogs' internal databases.
Affected instances span all supported platforms—Windows, Linux, and macOS—under default configurations. The source does not specify exact version numbers, referring generally to the standard configuration. This leaves the exact perimeter uncertain: while those who have customized registration or repository limits may have a reduced attack surface, the source does not quantify this variable.
Governance Crisis: Two Zero-Days in Six Months, Zero Patches
The timeline is the most troubling aspect of this disclosure. Gogs maintainers were notified "in mid-March 2026" and "acknowledged receiving the vulnerability report," but as of May 29, 2026, "no patch has been released." This two-and-a-half-month window represents a structural deficiency in vulnerability management rather than a mere operational delay.
This is not an isolated incident. The source places this event in a sequence: the previous zero-day, CVE-2025-8110 (CVSS 8.8), was disclosed by Wiz in December 2025. Only six months separate these two critical events. While CVE-2025-8110 is a distinct, documented fact with an official NVD 8.8 HIGH rating, the new vulnerability had not yet been assigned a CVE identifier at the time of the report.
The source provides no details regarding Gogs' organizational structure, such as the number of active maintainers, funding model, or project governance. These missing data points make it difficult to distinguish between a resource crisis, strategic disagreement, or progressive abandonment. What is documented is the outcome: a critical vulnerability with a public Metasploit module and no official countermeasure.
Why It Matters
The brief does not document any specific corrective measures released by Gogs maintainers or official mitigation actions recommended to users. The source does not specify whether alternative configurations exist that could fully disable the attack path without removing essential functionality.
The dossier does not quantify the number of Gogs instances exposed to the internet, nor does it verify if the vulnerability was actively exploited prior to disclosure. The status of the patch at the time of reading is unknown; the news is dated May 29, 2026, and any subsequent developments are outside the scope of the brief.
The source does not detail the technical structure of the Metasploit module released by Rapid7, its execution requirements, or the specific IoCs published. Their existence is documented, but their operational content is not described.
While editorial comparisons to alternatives like Gitea or GitLab are suggested, the source does not provide a comparative analysis. The risk of dependency on projects with a single organizational point of failure remains an editorial observation rather than an empirical data point provided by the source regarding the security status of those alternatives.
Unresolved Questions
Is the vulnerability only exploitable with open registration? The source describes the most direct path via self-created accounts but does not rule out legitimate authenticated users abusing the same flaw. Disabling public registration reduces the surface area but does not necessarily eliminate internal risk.
What is the exact nature of the data at risk? The citation lists specific categories: password hashes, API tokens, SSH keys, and 2FA secrets. The source does not clarify if these are stored in plaintext or hashed, nor which algorithms are used. The ability to "dump" implies database access, but not necessarily immediate readability of all fields.
Why have maintainers failed to release a patch? The source reports only the acknowledgment and the absence of a fix. Motivations, internal timelines, or design discussions are not documented. There is a clear information limit: it is known that there is no patch, but it is not known why.
The Gogs crisis exemplifies a broader issue in critical open-source infrastructure: the security of thousands of installations depends on the response capacity of a often-small number of volunteers. When that capacity fails, responsible disclosure becomes a public announcement without a technical counterweight, and a Metasploit module transforms a theoretical flaw into a practically off-the-shelf attack.
Information is based on the cited source and is current as of the publication date.