Skip to content

Gogs CVE-2026-52813 path-traversal RCE (and CVE-2026-52810 push bypass, GHSA-6vxv-wg6j-5qwp XSS)

Summary

Aikido (via Aikido Attack AI pentesting) reported a set of flaws in Gogs, the open-source Git hosting platform (self-hosted Git like GitHub/GitLab, built heavily on the git CLI). The full write-up was published August 19, 2026. The headline is CVE-2026-52813 (GHSA-c39w-43gm-34h5), a path traversal to Remote Code Execution. Gogs maintainers — historically slow to patch — fixed all reported issues in Gogs 0.14.3, but one unpatched bypass of a reported vulnerability and the push-authorization bypass (CVE-2026-52810) remain. Aikido recommends using a different self-hosted Git solution for now, since Gogs is not actively maintained.

Tags

CVE-2026-52813 — path traversal to RCE (fixed in 0.14.3)

Root cause: Gogs's UserPath() in repox.go determines where each user's repositories live on the filesystem by joining the username with the configured repositories root directory. Path joining without sanitization is dangerous because ../ sequences escape the intended directory.

  • Usernames are sanitized at registration via the AlphaDashDot binding (only letters, numbers, -, _, .) — so a registered user cannot inject ../.
  • Organizations are not sanitized. The organization UserName field bypasses that check, so an attacker can create an organization named ../../../../../tmp/test, causing UserPath() to resolve outside the intended directory and write to arbitrary filesystem locations — reachable only through the API.

The result is Remote Code Execution on the Gogs host (the traversal writes outside the repo root onto the wider filesystem). Affected: Gogs ≤ 0.14.2; fixed in 0.14.3.

CVE-2026-52810 — push authorization bypass on read-only repos (UNPATCHED)

A logic bug that lets an attacker write to read-only repositories. Aikido states all versions are currently vulnerable — there is no officially fixed version. Aikido flags Gogs instances with a "high" alert. A manual code patch is provided in the Aikido post.

GHSA-6vxv-wg6j-5qwp — XSS in the Jupyter rendering library (notebookjs)

Gogs renders .ipynb notebooks via the notebookjs library. Gogs's backend uses bluemonday to sanitize notebookjs output before appending to the DOM (so <u>te<script>1</script>st</u> becomes <u>test</u> — safe). The vulnerability is inside notebookjs itself: during Markdown→HTML conversion for Markdown cells, it creates a temporary element and assigns .innerHTML to it. The assignment triggers events even though the element is never added to the DOM (e.g., an <img> with a failing src= fires onerror=). A crafted .ipynb therefore triggers XSS while rendering, regardless of Gogs's sanitization.

Delivery: an attacker can place such files in their own repositories, in Pull Requests (rendered on "View file"), or by sending a user a link to the payload file.

Why this matters

  • Gogs has a long history of slow-to-fix RCEs; this round is positive (all reported issues fixed in 0.14.3), but the project is not actively maintained, so active vulnerabilities are likely to persist and the unpatched CVE-2026-52810 + bypass keep the risk high.
  • The organization-username path traversal is a good general pattern: any user-controlled path component that skips the sanitization applied to a sibling entity (users vs. orgs) is a traversal/escape primitive.
  • Aikido's broader point: integrating Git into an application is hard to do safely and the filesystem pitfalls are often critical-impact; with AI finding vulnerabilities fast, fix velocity and pentest coverage matter.

Defender priorities

  1. Upgrade Gogs to 0.14.3 to close CVE-2026-52813 and the fixed issues. This does not close CVE-2026-52810.
  2. For CVE-2026-52810 (no fixed version): apply Aikido's manual code patch, or restrict write access so read-only repositories cannot accept pushes from untrusted principals.
  3. Assess the org-username traversal surface in any Gogs derivative or self-hosted Git that joins user/org-controlled path segments without sanitization.
  4. Treat Jupyter/notebook rendering as an XSS vector: don't rely on outer HTML sanitization alone when a rendering library assigns attacker-controlled content to .innerHTML; validate/sanitize notebook payloads at render time.
  5. If Gogs is internet- or intranet-exposed and you cannot patch/patch-velocity-maintain it, Aikido recommends migrating to a different self-hosted Git solution until the project's security posture stabilizes.

Assessment limits

  • Based on Aikido's public post (and its AI-pentest report excerpts); version boundaries and the "all versions affected" claim for CVE-2026-52810 are Aikido's.
  • Gogs maintainers fixed the reported issues in 0.14.3; the one remaining unpatched bypass and CVE-2026-52810 have no official fix as of the post.
  • No reported in-the-wild exploitation of CVE-2026-52813; the report is via responsible disclosure / AI pentesting.

Sources