Skip to content

Back to the catalog

Yet another RCE in Gogs, but it's fixed this time!
aikido.devwriteup

Yet another RCE in Gogs, but it's fixed this time!

Aikido researchers detail how an AI pentesting agent found a path traversal in Gogs' organization name handling (CVE-2026-52813), which they manually escalated to full Remote Code Execution by planting a bare git repository inside a worktree and overwriting its hooks/update file to trigger command execution on push. The post also covers a git-receive-pack/git-upload-pack service parameter confusion causing an authorization bypass allowing writes to private repos by read-only users (CVE-2026-52810, with an unpatched case-sensitivity bypass and manual code fix provided), and a stored XSS in Gogs' Jupyter notebook rendering via an outdated notebookjs library that bypasses bluemonday sanitization via onerror handlers set during innerHTML assignment.

TL;DR Deep-dive exploitation writeup chaining a Gogs organization-name path traversal into full RCE via git hooks, plus an unpatched receive-pack/upload-pack auth bypass and a notebookjs stored XSS.
Document

What it is

CVE-2026-52813 (GHSA-c39w-43gm-34h5) is a path-traversal RCE in Gogs, found by Aikido's AI pentest agents. The summary names the bug; the page adds the fix boundary: all reported issues are patched as of Gogs 0.14.3 — a notable break from Gogs' history of RCEs that lingered until public disclosure forced a release.

How it works

UserPath() in repox.go builds a user's repo directory by joining the configured root with the (lowercased) username, unsanitized:

func UserPath(user string) string {
    return filepath.Join(conf.Repository.Root, strings.ToLower(user))
}

User registration blocks ../ via the AlphaDashDot binding, but the createOrgRequest struct binds UserName with only Required — no character filter. Creating an org named ../../../../../tmp/test via POST /api/v1/user/orgs makes UserPath() resolve outside the root; creating a repo under that org then writes a bare git repository (metadata only, no worktree) to the attacker-chosen path. The page demonstrates the write landing at /tmp/test/repo1.git. The escalation from arbitrary bare-repo write to full RCE is where the fetched text cuts off (it flags UI file editing as the next step but does not complete it).

Preconditions / Affected

Gogs before 0.14.3. Requires an authenticated account able to mint an API token and call the org/repo creation endpoints — the traversal is only reachable through the API, not the web registration path.

What to do

Upgrade to Gogs 0.14.3, which fixes CVE-2026-52813, the read-only-repo write bug (CVE-2026-52810), and the Jupyter-renderer XSS (GHSA-6vxv-wg6j-5qwp).

Caveats

Upgrading is not sufficient on its own: the post states there is still one unpatched bypass of a reported vulnerability that their agents found, for which Aikido provides a manual code patch in the post. An engineer relying only on 0.14.3 should retrieve that manual patch from the source page rather than assume the upgrade closes everything. The specific vulnerability the bypass targets is not identified in the fetched excerpt.

Organisations named here

  • GHSA-6vxv-wg6j-5qwp
  • GHSA-c39w-43gm-34h5
  • GHSA-wmfg-5p4h-5fw3

CVEs named here

  • CVE-2026-52813
  • CVE-2026-52810

Technologies named here

  • Gogs
  • Aikido Attack
  • notebookjs
  • Aikido Autofix
  • AI Pentesting
  • bluemonday
  • mitmproxy
  • git CLI
  • git
  • Go

Techniques named here

  • Path traversal via organization username
  • RCE via nested bare repository git hooks
  • Stored XSS via innerHTML assignment before sanitization
  • Path traversal