CVE-2024-39930: Gogs built-in SSH server argument injection leads to RCE
The short version: Gogs — the lightweight self-hosted Git service — has an argument-injection flaw in its built-in SSH server (CVE-2024-39930). An authenticated user who can open an SSH connection can inject a malicious --split-string option and reach remote code execution on the host. It's fixed in 0.13.1 and later. If you run Gogs with the built-in SSH server on Linux, upgrade.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — post-authentication RCE on a low auth bar |
| CVSS v3.1 (NVD) | 9.9 — Critical · AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
| EPSS | ~7.26% · 93rd percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not confirmed in the wild |
| Vulnerability type | CWE-88 argument injection → remote code execution |
| Requires authenticated session? | Yes — an authenticated user, with the built-in SSH server enabled |
| Affected | Gogs through 0.13.0 (Linux; Windows installations unaffected) |
| Fixed in | 0.13.1 |
What you need to know
Gogs can run its own built-in SSH server. In internal/ssh/ssh.go, user-controlled input reaches a command without proper neutralization, so an authenticated attacker can smuggle an extra argument — a malicious --split-string (env) option — into the process. That argument injection is enough to execute code on the server.
A few points that shape the real-world risk:
- It requires an account, but that bar is often low. Many Gogs instances allow self-registration, which turns "authenticated" into "anyone who signs up."
- It requires the built-in SSH server. Deployments that front Gogs with the host's OpenSSH aren't in scope for this specific path.
- Windows is unaffected. The flaw is specific to the non-Windows code path.
How serious we see it
Critical — with a Critical base score for good reason.
The NVD scores it 9.9 because the impact is complete once you're in, and the privilege requirement is only "low." We rate the practical severity High rather than Critical because exploitation needs an authenticated session and the built-in SSH server, which narrows the population — but where self-registration is on, treat it as close to unauthenticated. The reassuring part is that it's bounded and fixable: a single upgrade closes it, and you can tell quickly whether you're affected.
Recommendations
Straight from the vendor and the disclosing researchers:
- Patch now. Upgrade to Gogs 0.13.1 or later.
- Reduce the auth bar. Disable open self-registration on internet-facing instances so "authenticated" means "trusted."
- Reconsider the built-in SSH server. If you don't need it, disable it; restrict who can reach it.
- Confirm your exposure first. Verify whether you run an internet-facing Gogs with the built-in SSH server on a non-Windows host.
How BreachRisk sees it
BreachRisk discovers internet-facing Gogs instances in your external footprint, fingerprints the version from the application's responses, and flags exposure tied to this CVE. Because reaching this flaw requires an authenticated SSH session, it isn't something we safely exploit — we detect and flag the exposed, affected version so it's on your radar with the context that matters.
That outside-in view means a self-hosted Git server on a developer subdomain is mapped and version-checked, so a flaw like this surfaces as a specific finding rather than a blind spot.