In Gogs—a popular solution for self-hosting Git repositories—a critical remote code execution (RCE) vulnerability with a CVSS 9.4 rating has been discovered, according to Rapid7 researchers. The vulnerability allows any authenticated user to execute arbitrary commands on the server by creating a pull request with a malicious branch name. At the time of publication, no patch is available, and a public Metasploit module already automates the full exploitation chain. Administrators of Gogs instances must immediately apply workarounds: disable registration, restrict repository creation, and audit rebase-merge settings.
Exploitation mechanism: argument injection in git rebase
The essence of the vulnerability lies in insufficient sanitization of branch names when performing the “Rebase before merging” operation. As reported by researcher Jonah Burgess from Rapid7, an attacker creates a pull request with a branch name containing the --exec flag, which is injected into the git rebase command. According to the official Git documentation, the --exec parameter accepts an arbitrary shell command that is executed after each commit is applied during the rebase process.
A key aspect of the vulnerability is the extremely low barrier to entry for an attacker. According to the researchers, exploitation does not require administrator privileges or interaction with other users. On a Gogs instance with default configuration, the attack chain looks as follows:
- The attacker registers an account on the target instance
- Creates their own repository (the creator automatically becomes the owner)
- Enables the rebase-merge option—this is the only toggle in the settings
- Creates a pull request with a malicious branch name containing a
--execinjection - When the rebase merge is performed, the arbitrary command is executed on the server
In an alternative scenario, if repository creation is restricted, it is sufficient for the attacker to have write access to any repository in which rebase merging is already enabled. The vulnerability reportedly affects all supported platforms: Windows, Linux, and macOS.
Lack of a patch and exploit availability
According to Rapid7, the vulnerability was reported to the project maintainer on 17 March 2026; however, at the time of disclosure, no fix is available. The vulnerability has not been assigned a CVE identifier, which complicates tracking it through standard databases. The CVSS 9.4 score comes from Rapid7 and has not been confirmed by the vendor or NVD.
The situation is exacerbated by the existence of a public Metasploit module that automates the full exploitation chain for Linux and Windows. The module supports two operating modes:
- Default mode: a temporary repository is created under the attacker’s account, the exploit is executed, and the repository is deleted. The only trace is an HTTP 500 entry in the server logs.
- Targeted mode: exploitation of an existing repository to which the attacker has write and merge access. In this case, more artifacts remain.
The minimal footprint in logs when using the first mode makes detecting the attack significantly more difficult for incident response teams.
Impact assessment
Successful exploitation of the vulnerability, according to the researchers, may lead to the following consequences:
- Full compromise of the server with access to all repositories on the instance
- Extraction of credentials and secrets from stores
- Lateral movement to other systems reachable over the network
- Modification of code in any hosted repository—a potential software supply chain attack vector
- Cross-user data leakage: reading private repositories of other users on the same server
The last point is particularly critical for organizations using a shared Gogs instance for multiple teams or projects. Compromise of a single low-privilege account can potentially expose the entire body of hosted code.
Mitigation recommendations
In the absence of an official patch, the following measures must be applied immediately:
- Disable open registration: set
DISABLE_REGISTRATION = truein theapp.inifile to prevent untrusted users from creating accounts - Restrict repository creation: set
MAX_CREATION_LIMIT = 0inapp.iniso that users cannot create repositories on their own - Audit rebase-merge settings: check all repositories for the enabled “Rebase before merging” option and disable it wherever it is not strictly necessary
- Review server logs: pay attention to HTTP 500 entries, which may indicate exploitation attempts
- Consider migration: for organizations with high security requirements, evaluate migrating to actively maintained alternatives such as Gitea (a Gogs fork with a more active security update cycle)
The combination of a missing patch, a publicly available Metasploit module, and a low exploitation threshold creates a window of heightened risk for all Gogs instances. The top priority is to disable registration and rebase merging on all instances exposed to the internet or untrusted network segments until an official fix is released by the project maintainer.