Researchers Detail Gogs RCE, Push Authorization Bypass and Notebook XSS
Summary
Aikido details three Gogs flaws: path-traversal RCE (CVE-2026-52813), a Git push authorization bypass (CVE-2026-52810), and stored XSS in .ipynb rendering. The RCE is fixed in 0.14.3; the bypass remains exploitable through a reported incomplete fix.
Key points
- Aikido traces CVE-2026-52813 to unsanitized organization names passed to Gogs' repository-path function, allowing an API-created organization to place repositories outside the configured root.
- The researchers chained the traversal with a nested bare Git repository and writable worktree to modify its update hook; a subsequent push executed a command as the git user.
- Aikido says the RCE affects Gogs 0.14.2 and earlier and was fixed in version 0.14.3.
- CVE-2026-52810 stems from authorization treating a receive-pack request as a read when given a git-upload-pack service parameter; the researchers demonstrated a read-only collaborator pushing to a private repository.
- The authors report no officially fixed version for the push bypass. They say a route-validation fix is incomplete because uppercase RECEIVE-PACK can evade its check, and provide a manual patch.
- GHSA-6vxv-wg6j-5qwp is a stored XSS flaw in .ipynb rendering: the reported cause is outdated notebookjs processing untrusted Markdown through innerHTML, triggering events before Gogs' output sanitizer.
Article Details
- Attack Vectors
- An organization name submitted through the Gogs API can contain path-traversal sequences, causing repositories to be created outside the configured repository root.
- A nested bare repository placed inside an editable worktree can have its hooks file modified through a Git push; a later push to that repository executes the hook and achieves remote command execution as the git user.
- For CVE-2026-52810, adding service=git-upload-pack to a git-receive-pack request causes authorization to treat a write operation as a read, allowing a read-only collaborator to push changes to a repository.
- A crafted .ipynb Markdown cell can trigger stored XSS when notebookjs assigns rendered content to a temporary element's innerHTML; the article demonstrates an img onerror payload.
- Defensive Notes
- The article reports that Gogs 0.14.3 fixes the reported RCE; it identifies versions 0.14.2 and below as affected.
- The article says CVE-2026-52810 has no officially fixed version and that all versions are vulnerable. It provides a source patch that lowercases the action and compares the service parameter case-insensitively, and recommends rebuilding Gogs after applying it.
- The article recommends using a different self-hosted Git solution for the time being, citing that Gogs is not being actively maintained.
MITRE ATT&CK
T1059.004 · Unix ShellA Git hooks/update file is modified to run `id > /tmp/pwned` when a push triggers the hook.T1059.007 · JavaScriptThe crafted .ipynb payload uses an img onerror handler to execute JavaScript when the notebook is rendered.T1190 · Exploit Public-Facing ApplicationThe demonstrated attacks exploit vulnerabilities in the Gogs API and Git HTTP endpoints to achieve repository writes and server-side code execution.T1565.001 · Stored Data ManipulationThe receive-pack authorization bypass lets a read-only collaborator push changes to a repository, including changes the article warns could hide malware.
CVE
CVE-2026-52810most technically interesting. But I’ll also explain a logic bug to write on read-only repositories (CVE-2026-52810), together with an XSS vulnerability in the Jupyter rendering library Gogs was usingCVE-2026-52813This post will primarily focus on the Remote Code Execution vulnerability (CVE-2026-52813), as it is the most technically interesting. But I’ll also explain a logic bug to write on read-only repositories