Gogs Organization-Name Path Traversal to RCE via Git Hooks — CVE-2026-52813
by thecodeb0ss (GitHub / t.me/thecodeb0ss) · 2026-07-05
- Severity
- Not disclosed
- CVE
- CVE-2026-52813
- Category
- web
- Affected product
- Gogs (self-hosted Git service), organization creation feature
- Affected versions
- Not disclosed in repo
- Disclosed
- 2026-07-05
- Patch status
- patched
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-07-05 |
| Last Updated | 2026-07 |
| Author / Researcher | thecodeb0ss (GitHub / t.me/thecodeb0ss) |
| CVE / Advisory | CVE-2026-52813 |
| Category | web |
| Severity | Not disclosed |
| CVSS Score | Not disclosed |
| Status | PoC |
| Tags | gogs, path-traversal, git-hooks, rce, authenticated, account-takeover, self-hosted-git |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | Gogs (self-hosted Git service), organization creation feature |
| Versions Affected | Not disclosed in repo |
| Language / Platform | Python 2 (PoC exploit script) |
| Authentication Required | Yes — requires valid credentials for a Gogs account on the target instance |
| Network Access Required | Yes |
Summary
Gogs fails to properly sanitize the organization name supplied at organization-creation time, allowing an authenticated attacker to embed path-traversal sequences (../../...) in the name so that it resolves outside the intended organization directory and into another repository’s path on disk (e.g., /var/lib/gogs/repos/<user>/<repo>/.git). Because Gogs installs an executable Git hooks directory (.git/hooks/) for every managed repository, the attacker creates a repository named codeb0ss_hooks under the traversal-crafted “organization,” then pushes a commit containing a malicious update hook. When Git subsequently invokes that hook (e.g., during a push to the target repository), the attacker’s shell commands execute on the server. The PoC script automates the full chain: login, malicious organization creation with the traversal payload, hook-repository creation, and pushing a hook that runs id and writes the output to /tmp/codeb0ss_pwned.txt, confirming remote code execution.
Vulnerability Details
Root Cause
The organization-name input on Gogs’ /org/create (and subsequent /org/<name>/new repository-creation) endpoints is used directly to construct a filesystem path under Gogs’ repository storage root without adequate validation/sanitization of path-traversal sequences, allowing an attacker-supplied name to escape the intended organization directory and land inside another repository’s .git directory tree, including its hooks/ subdirectory.
Attack Vector
- Attacker authenticates to the target Gogs instance with valid (even low-privileged) credentials.
- Attacker crafts a path-traversal payload for the organization name, e.g.
../../../../../../var/lib/gogs/repos/admin/demo/.git(repeated../sequences to reach the repository storage root, then a path into a target repo’s.gitdirectory). - Attacker creates this “organization” via
POST /org/create. - Attacker creates a repository named
codeb0ss_hooksunder that crafted organization path viaPOST /org/<traversal-path>/new, causing Gogs to materialize ahooks/directory at the traversed location. - Attacker prepares a local Git repo containing a malicious
.git/hooks/updatescript (e.g.,id > /tmp/codeb0ss_pwned.txt), commits it, and force-pushes it to<target>/<traversal-path>/codeb0ss_hooks.git. - When the resulting
updatehook is later invoked by Git on the server (e.g., on a subsequent push/update to the traversed target repository), the attacker’s shell commands execute with the privileges of the Gogs service account.
Impact
Remote code execution on the Gogs host as the service account running Gogs, achievable by any authenticated user (regardless of assigned permissions on the target repository), potentially leading to full server compromise, data exfiltration, or lateral movement.
Environment / Lab Setup
Target: Gogs instance (self-hosted Git service) with organization creation
enabled for authenticated users; repos stored at /var/lib/gogs/repos/
Attacker: Python 2, `requests` library, local `git` CLI
Proof of Concept
PoC Script
See
codeb0ss_CVE-2026-52813.codeb0ssin this folder (a plain Python 2 script; the unusual.codeb0ssextension is preserved as distributed by the original author — rename to.pyor invoke explicitly withpython2to run).
| |
The script logs into the target Gogs instance with the supplied credentials, generates a path-traversal organization name pointing at /var/lib/gogs/repos/admin/demo/.git (hardcoded target user/repo of admin/demo in this version), creates that organization and a codeb0ss_hooks repository under it, then builds and force-pushes a local Git repo containing a malicious .git/hooks/update script that writes id output to /tmp/codeb0ss_pwned.txt on the server, confirming code execution when the hook fires.
Detection & IOCs
Signs of compromise:
- Organization or repository names containing
../sequences in Gogs logs - Unexpected or modified files under
.git/hooks/(e.g.,update) for repositories the acting user should not have write access to - Outbound shell command execution originating from the Gogs service process/user
Remediation
| Action | Detail |
|---|---|
| Primary fix | Apply the upstream Gogs patch that sanitizes/validates organization and repository names against path-traversal sequences before using them to construct filesystem paths |
| Interim mitigation | Restrict organization-creation privileges to trusted/admin users only, run the Gogs service account with least-privilege filesystem permissions, and monitor .git/hooks/ directories for unauthorized modification |
References
Notes
Mirrored from https://github.com/thecodeb0ss/CVE-2026-52813 on 2026-07-05. During vetting, the repository was found to open with a Telegram self-promotion banner (t.me/thecodeb0ss) and to log successful hits locally in a mass-scan style (appending target/credentials to codeb0ss_gogs_exploited.txt on success), consistent with promotional/mass-scanning framing rather than a purely research-oriented writeup. No hidden backdoor, dropper, or other malicious payload was found in the script itself — the RCE payload (id > /tmp/codeb0ss_pwned.txt) is transparent and matches the documented vulnerability. Flagged here for the promotional/mass-scan framing, not for hidden malware.