Your Self-Hosted Gogs Server Has an Authenticated RCE (CVE-2026-52806). The Fix Shipped June 7 — Patch to 0.14.3 This Weekend.
If you run your own Gogs server, here's your weekend job: upgrade to 0.14.3. Rapid7 disclosed an argument-injection bug, tracked as CVE-2026-52806, that lets an authenticated user with write or merge access run arbitrary shell commands on the host as the Gogs process user. The maintainer accepted Rapid7's patch and released 0.14.3 on June 7. Until you're on it, anyone you've given write or merge access to a repo can potentially own the box.
A lot of solo operators self-host Git specifically to get out from under platform risk: no GitHub policy changes, no surprise pricing, your code on your own VPS. That's a reasonable call. The trade is that the patching burden is now yours, and this is exactly the kind of bug that bill comes due on.
What the bug actually is
The mechanism is almost embarrassingly simple, which is what makes it dangerous. Gogs has a "Rebase before merging" option for pull requests. When that merge runs, Gogs passes the PR's branch name straight to git rebase via raw process execution, and it does so without the -- end-of-options delimiter that tells git "everything after this is an argument, not a flag."
That missing -- is the whole vulnerability. Git's rebase supports an --exec flag that runs a shell command after each rewritten commit. So an attacker creates a branch whose name is a flag (something like --exec=<command>), opens a pull request, and triggers the rebase merge. Git dutifully reads the branch name, sees what looks like --exec, and runs the attacker's command on the server. No memory corruption, no exotic exploit chain. Just a name git was never supposed to treat as an instruction, treated as an instruction.
The affected versions are 0.14.2, the 0.15.0+dev line up to commit b53d3162, and every prior release that supports rebase-merge. If your Gogs predates June 7 and you've ever enabled that merge style, assume you're in scope.
Who's actually exposed
This is an authenticated bug, not an unauthenticated internet free-for-all, and that distinction matters for how worried you should be. The attacker needs write or merge access to a repository on your instance. That changes the threat model depending on how you run Gogs.
If your Gogs is a private, single-user or small-trusted-team instance with registration disabled and no untrusted accounts, your immediate exposure is low: the people who can trigger this are people you already trust with your code. If you've opened registration, run a public or community instance, accept contributors you don't personally vouch for, or hand out write access liberally, your exposure is real and you should treat this as urgent. The worst case is a public instance with open sign-up, because then "authenticated" is one click away from "anyone."
Either way, the fix is the same and it's cheap, so the right move regardless of your setup is to patch and stop reasoning about who might abuse it.
The ten-minute fix
Upgrade to Gogs 0.14.3. That's the actual answer, and it's the only one that fully closes the hole. How you do it depends on how you deployed: if you run the official Docker image, pull the 0.14.3 tag, recreate the container, and confirm the version in the admin panel; if you run a binary, swap it for the 0.14.3 release and restart the service. Back up your data directory and database first, the way you would before any upgrade.
If you genuinely can't upgrade this weekend, the stopgap is to reduce who can reach the vulnerable path. Disable the "Rebase before merging" merge style on your repositories so the dangerous code path doesn't run. Turn off open registration if it's on, and review who currently holds write or merge access and trim anyone who doesn't need it. These are mitigations, not fixes: the only thing that removes the vulnerability is the patched binary, so treat any workaround as a bridge to upgrading, not a destination.
What I'd actually do, and the honest caveat
I'd patch tonight and not overthink it. The upgrade is small, the fix is official, and the downside of waiting is the entire host. There's no clever risk calculation that beats "spend ten minutes and remove the problem."
The honest counter-take: for the median solo operator running a private Gogs with no untrusted users, this is not a five-alarm fire, and I'm not going to pretend your single-user code mirror is being actively hunted this week. It almost certainly isn't. The realistic attacker here is someone you've already let into a repo, which on a personal instance is nobody. But two things keep this on the list anyway. First, self-hosting choices drift: the instance you stood up as single-user a year ago may have picked up a collaborator or an open-registration setting you forgot about. Second, the cost of being wrong is total host compromise, against a fix that costs you a coffee's worth of time. That's the trade I take every time. Patch to 0.14.3, confirm the version, and get on with your weekend.
Author
Lukas
@lukcombinator