Critical Vulnerability in Gogs Enables Remote Code Execution via Path Traversal Exploit
A significant security concern has emerged regarding Gogs, the self-hosted Git service, which currently faces a critical vulnerability that threatens users’ servers. This vulnerability allows authenticated attackers to execute commands on the server by exploiting a path traversal flaw during the creation of organization names.
This vulnerability has been identified as CVE-2026-52813, with the discovery credited to Aikido security researcher Jorian Woltjer. The issue has since been addressed in Gogs version 0.14.3, making it imperative for users to upgrade to this version or later to safeguard their systems.
Mechanics of the Vulnerability
The root of this vulnerability lies in an API endpoint that inadequately sanitizes organization usernames, ultimately passing them to a filesystem path-construction routine. Gogs had employed the filepath.Join function to append an organization name to its configured repository root. While standard controls during account registration effectively restricted usernames to safe alphanumeric characters, as well as dashes, underscores, and periods, the organization-creation API did not enforce equivalent validation.
Thus, an authenticated attacker could exploit this oversight by supplying a malicious organization name containing ../ traversal sequences. This would compel Gogs to create a repository outside its designated storage path, leading to unforeseen anomalies and security exposures. For example, if an attacker provided a crafted organization name targeting a writable temporary location, such as /tmp, Gogs could inadvertently initialize a bare Git repository at the attacker’s chosen filesystem location, significantly breaching server security protocols.
Evolving Threats from Initial Exploit
Initially, this vulnerability appeared to only result in constrained file-write operations. A bare repository, which contains Git metadata but lacks a conventional working tree, restricted the ability to overwrite arbitrary application files directly. However, Woltjer subsequently demonstrated that Gogs’ web-based editing mechanism could serve as a vector to escalate this primitive exploitation into full remote code execution.
When users edit repository files through the Gogs web interface, the service creates temporary worktrees. An attacker could leverage this by first creating a legitimate repository with web editing capabilities, followed by using a traversal-named organization to introduce a malicious bare repository within the temporary worktree.
To further exploit this vulnerability, the attacker might clone the legitimate repository locally and commit a Git hook to a path such as traversal.git/hooks/update. Despite Gogs’ web editor blocking paths that include .git/, a standard Git push could circumvent this restriction due to a flaw in the validation logic. The logic looked for a path segment strictly named .git, allowing paths like traversal.git to successfully evade the check. As a result, subsequent API-driven commits to the nested repository could activate the malicious update hook, executing attacker-specified commands under the guise of the account used by the Git service.
Additional Concerns and Recommendations
Alongside this compromised functionality, the disclosure also sheds light on another vulnerability, classified as CVE-2026-52810. This separate weakness relates to authorization issues affecting Git HTTP requests. Gogs partially classified requests as read-only pulls based on a service query parameter while routing operations according to the request path. By providing service=git-upload-pack in a git-receive-pack request, an attacker could manipulate a push request to be erroneously treated as a pull. This allowed unauthorized users to potentially write to private repositories, further exacerbating the security risks involved.
Users are now advised to update to Gogs 0.14.3 or later to effectively mitigate CVE-2026-52813 and should thoroughly inspect their installations for suspicious organization names, unexpected repository paths, and unauthorized Git hooks. Increased vigilance is essential, particularly in monitoring upstream remediation efforts concerning the receive-pack authorization bypass.
The emergence of these vulnerabilities serves as a stark reminder of the critical need for stringent validation mechanisms and rigorous authorization boundaries. Such lapses can render Git hosting features into exploitable attack vectors, particularly in environments where repositories are utilized within automated continuous integration and deployment (CI/CD) workflows. In light of these developments, the emphasis on robust security practices has never been more crucial, as the implications of inaction may result in severe consequences for affected organizations and their data integrity.