A critical vulnerability in Gogs, the self-hosted Git service, could allow authenticated attackers to execute commands on the server by abusing path traversal during creation.
Tracked as CVE-2026-52813, the flaw was reported by Aikido security researcher Jorian Woltjer and fixed in Gogs version 0.14.3.
The issue stems from an API endpoint that accepted unsanitized organization usernames before passing them to a filesystem path-construction routine.
Gogs used filepath.Join to append an organization name to its configured repository root. While standard account-registration controls restricted usernames to safe alphanumeric characters, dashes, underscores, and periods, the organization-creation API did not enforce the same validation.
Critical Gogs Flaw Enables Remote Code Execution
An authenticated attacker could supply an organization name containing ../ traversal sequences, directing Gogs to create a repository outside its intended storage path.
For example, a crafted organization name could target a writable temporary location such as /tmp. Gogs would then initialize a bare Git repository at the attacker-selected filesystem location.
Initially, this behavior appeared to offer only a constrained file-write primitive. Bare repositories contain Git metadata rather than a conventional working tree, limiting opportunities to overwrite arbitrary application files directly.
However, Woltjer demonstrated that Gogs’ web-based editing mechanism could be exploited to convert the primitive into remote code execution. Gogs creates temporary worktrees when users edit repository files through its web interface.
An attacker could first create a legitimate repository that supports web editing, then use a traversal-named organization to place a malicious bare repository within the temporary worktree.
From a local clone of the legitimate repository, the attacker could commit a Git hook to a path such as traversal.git/hooks/update. Although Gogs’ web editor blocks paths containing .git/, a standard Git push could bypass that restriction.
The validation logic looked for a path segment named exactly .git, allowing a directory such as traversal.git to evade the check. A subsequent API-driven commit to the nested repository would trigger the malicious update hook, executing attacker-controlled commands as the account used by the Git service.
The disclosure also highlights CVE-2026-52810, a separate authorization weakness affecting Git HTTP requests. Gogs partly classified requests as read-only pulls based on a service query parameter, while routing operations based on the request path.
Supplying service=git-upload-pack to a git-receive-pack request could cause a push to be treated as a pull, potentially enabling read-only users to write to private repositories. Woltjer reported that the authorization issue affected private repositories and deployments that require authentication to view.
Administrators should upgrade to Gogs 0.14.3 or later to address CVE-2026-52813, inspect instances for suspicious organization names, unexpected repository paths, and rogue Git hooks, and closely monitor upstream remediation efforts for the receive-pack authorization bypass.
The flaws demonstrate how weak identifier validation and blurred authorization boundaries can turn Git hosting features into server-side attack paths, especially in environments where repositories feed automated CI/CD workflows.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC
