In today’s episode of "Input Validation is Hard," the popular lightweight Git service Gogs has been outed for harboring a critical remote code execution vulnerability. Clocking in at a CVSS 9.4, and notably lacking a CVE, because who needs official tracking when you have chaos. This flaw lets essentially anyone with a login hand out shells like Halloween candy.
Security researcher Jonah Burgess over at Rapid7 detailed the exploit, which is less of an intricate cyber-heist and more of an abuse of standard Git mechanics. The vulnerability abuses the "Rebase before merging" operation. For the uninitiated, git rebase is the pristine developer’s tool of choice for rewriting history to pretend they code in straight, clean lines. Unfortunately, the git rebase command also supports an --exec flag, which executes shell commands after each commit is replayed.
Because Gogs apparently trusts user input more than a golden retriever trusts a stranger with a tennis ball, an attacker can simply create a pull request with a maliciously crafted branch name. That name injects the --exec flag directly into the backend git operation. Bam. Arbitrary code execution as the Gogs system user.
The barrier to entry here is embarrassingly low. You don't need admin privileges. You don't need to socially engineer the DevOps guy. If the Gogs instance is running its default configuration, an attacker just registers an account, makes a dummy repo, toggles on rebase merging in the settings, and fires the payload. The entire kill chain is a zero-click exploit for the victim, requiring zero interaction from anyone else on the server. If the admin actually bothered to restrict account creation, the attacker just needs write access to any existing repository that allows rebase merges.
The punchline? The bug was reported to the maintainer back in March, and it’s still sitting there, unpatched, like a rotting fish in the breakroom microwave.
The post-exploitation landscape is fully unrestricted. Once that --exec triggers, the attacker owns the underlying server, can dump all credentials, read every private repository across all tenants on the shared instance, and pivot to whatever internal network the server is connected to. And there are over a thousand of these boxes sitting naked on the public internet, plus an untold number hiding behind "secure" internal network VPNs that are about to get laterally flattened.
Since a patch is apparently a pipe dream right now, the only mitigation is neutering the platform. Admins have to edit their app.ini to lock down user registration (DISABLE_REGISTRATION = true) and kill repo creation (MAX_CREATION_LIMIT = 0).
To make matters worse, or better, depending on which side of the terminal you sit, Rapid7 already spoon-fed the masses a Metasploit module that automates the whole thing for Windows and Linux. The module even has an OpSec-friendly mode: it spins up a temporary repo under the attacker's account, pops the shell, and burns the repo to the ground. The only forensic footprint left behind is a generic HTTP 500 error in the server logs. Good luck hunting that down.
