Self-hosted Git servers rarely make front-page news. Yet one flaw in Gogs has security teams reviewing every internal deployment this week. An authenticated attacker can achieve remote code execution on the host simply by opening a pull request. No administrator rights required. No victim interaction. And, as of May 29, 2026, no patch exists.
The vulnerability carries a 9.4 CVSS score. It stems from argument injection into git rebase. Researchers discovered it months ago. The project maintainers received the report on March 17. They acknowledged receipt. Then silence.
Rapid7 researcher Jonah Burgess laid out the mechanics in detail. “The vulnerability allows any authenticated user to achieve remote code execution (RCE) on the server by creating a pull request with a malicious branch name that injects the –exec flag into git rebase during the ‘Rebase before merging’ merge operation,” he said. (Rapid7)
Short and simple. The attack lives inside the attacker’s own repository. Gogs ships with open user registration by default. Anyone can sign up. Create a repository. Toggle one setting. Craft a branch name that begins with --exec=. Open a pull request. When the server performs the rebase-before-merge, Git interprets the branch name as a command flag. The payload executes as the Gogs process user. Done.
Branch names can contain dashes, equals signs, and shell metacharacters. Git accepts them. The validation routines in Gogs call git rev-parse --verify before creating the pull request. That command treats the malicious string as a legitimate ref once the branch exists. Later, raw process.ExecDir passes it straight to git rebase without a -- separator. The gap has persisted while similar injection issues received fixes in other code paths.
Impact scales quickly. The Gogs process, often running as user git, enjoys read-write access to every repository stored under a single root directory. One successful execution hands the attacker the entire instance. Private repositories of other tenants. Database credentials. API tokens. SSH keys. 2FA secrets. From there lateral movement becomes routine. Code tampering leaves almost no audit trail if the attacker avoids the web interface.
Default installations make the attack frictionless. Repository creators become owners automatically. Rebase-before-merge sits one checkbox away. On locked-down instances where registration or repo creation carries restrictions, any user with write access to an existing rebase-enabled repository can still trigger the chain. The flaw affects Linux, macOS, and Windows alike. Docker images, binary deployments, source builds, all vulnerable.
Exposure remains modest on the public internet. Shodan data cited by researchers shows roughly 1,141 instances with the telltale login page. Yet Bleeping Computer reports Shadowserver now tracks more than 2,400 exposed Gogs servers, concentrated in Asia and Europe. The true footprint sits higher. Most organizations place these systems behind VPNs or inside corporate networks where one compromised developer account could hand over the keys.
Burgess went further. He built a Metasploit module that automates the full attack on both Linux and Windows targets. Two modes exist. The default creates a temporary repository under the attacker’s account, runs the exploit, then deletes the repo. Server logs record little more than an HTTP 500. The second mode targets an existing repository the attacker already controls. Artifacts remain. The repository ends up in a corrupted partial-rebase state, limiting reuse. But the code has already run.
This marks the latest chapter in a string of argument-injection problems for Gogs. Past CVEs addressed git tag, git diff, release deletion, and the built-in SSH server. Each time developers added --end-of-options or migrated calls to a hardened library. The merge logic in internal/database/pull.go never received the same treatment. It bypasses the safe API entirely.
Industry observers note the pattern. Gogs carries roughly 50,000 stars on GitHub. Teams at universities, small companies, and open-source projects favor its lightweight footprint. Yet maintenance appears thin. Multiple prior RCE-class bugs surfaced in 2024 and 2025, some actively exploited before patches landed. One earlier flaw, tracked separately as CVE-2025-8110, allowed symlink-based file writes and saw wild exploitation for months before fixes arrived. CISA added it to the Known Exploited Vulnerabilities catalog. Administrators received days to patch federal systems.
Here the timeline stretches. Disclosure occurred in March. No patch by late May. No public advisory from the project. Users cannot wait. Defenders must act on configuration alone.
Three concrete steps reduce exposure immediately. Set DISABLE_REGISTRATION = true in app.ini. Block new accounts from untrusted sources. Next, enforce MAX_CREATION_LIMIT = 0 globally or per user to prevent casual repository creation. Finally, audit every repository for the rebase-before-merge option and disable it where possible.
These controls do not eliminate risk for users who already hold write access to affected repositories. They shrink the pool of potential attackers dramatically. Organizations running Gogs in shared multi-tenant fashion should treat every instance as compromised until further notice. Isolate the server. Rotate credentials stored on it. Review logs for unexpected 500 errors that reference strange branch names containing --exec.
The Metasploit module makes testing trivial. Red teams already possess it. Threat actors read the same reports. Time favors the attacker until maintainers respond or the community forks the project with a fix.
Self-hosted Git tools form the backbone of countless development pipelines. When one link grants full server control with a single pull request, the trust model fractures. Teams that once viewed Gogs as simple and sufficient now confront the cost of unpatched foundational software. The question is no longer whether the bug will be exploited. It is how many instances will fall before configuration changes or an official patch arrives.
WebProNews is an iEntry Publication