CVE-2026-52813: Gogs path traversal in organization name results in RCE through Git hooks

Gogs (self-hosted Git service) before 0.14.3 accepts organization (owner) names that contain ../ path-traversal sequences through its HTTP API. Because the internal helpers repoutil.UserPath and repoutil.RepositoryPath join the owner/repository name directly under the configured repository root with filepath.Join and never clean .., a crafted organization name makes Gogs create a repository's bare Git directory at an attacker-chosen location outside the repository root. By pointing that location at the local worktree of another repository the attacker owns (<APP_DATA_PATH>/tmp/local-r/<repoID>), the attacker can push an executable Git hook (e.g. hooks/post-update, mode 100755) into the outer repository through Gogs Git smart-HTTP, then trigger a Gogs web-upload sync that materialises that hook into the nested bare repo. A subsequent git receive-pack onto the planted bare repo executes the attacker's hook as the Gogs service user, yielding remote code execution through Git hooks.

• Package/component affected: internal/repoutil/repoutil.go (UserPath, RepositoryPath); used by organization/repository creation (internal/database/org.go, internal/database/repo.go) and the Git HTTP/SSH serv path. The local-copy sync path internal/database/repo_editor.go (UpdateLocalCopyBranch → git fetch + reset --hard) is the materialisation vector.
• Affected versions: All Gogs versions before 0.14.3 (verified on v0.14.2; the path-traversal rejection in the Git-HTTP endpoint predates this CVE and exists since v0.13.0, but the organization-name traversal was not rejected until 0.14.3).
• Risk level: Critical. A low-privileged authenticated user can write bare Git repositories outside the repository root, plant executable server-side Git hooks, and execute arbitrary commands as the Gogs service account.

Impact Parity

• Disclosed/claimed maximum impact: Remote code execution through Git hooks (CVE-2026-52813 / GHSA-c39w-43gm-34h5).
• Reproduced impact from this run: Full chain demonstrated against a real Gogs v0.14.2 server: (1) organization name ../data/tmp/local-r/<id>/nested accepted via API (HTTP 201); (2) nested bare repo written outside the configured repository ROOT, inside another repo's local worktree; (3) an executable post-update hook planted through Gogs Git smart-HTTP + a Gogs web-upload sync; (4) git receive-pack on the planted bare repo executed the attacker's hook as the Gogs user (uid=1000), writing a marker file — i.e. arbitrary code execution. The fixed v0.14.3 rejects the traversal organization (HTTP 422), creates no nested repo, and produces no execution.
• Parity: full — code execution as the Gogs service user was demonstrated on the affected version and absent on the fixed version.

Root Cause

repoutil.UserPath/RepositoryPath computed filesystem paths with filepath.Join(conf.Repository.Root, strings.ToLower(user)) (and + repo + ".git") without sanitising ... filepath.Join resolves .., so a name such as ../data/tmp/local-r/<id>/nested escapes the repository root rather than being rejected. Gogs then:

1. os.MkdirAll's the traversed owner directory,
2. runs git init --bare and createDelegateHooks at the traversed path,
3. registers the repo in the database under the traversal owner name.

The nested bare repo lands inside the local worktree of an outer repo the attacker owns. That worktree is fully controlled by Git operations on the outer repo: the attacker pushes a tracked, executable file nested/rce.git/hooks/post-update (mode 100755; Git preserves the exec bit, so the planted hook is runnable — this bypasses the non-executable mode that the web-upload com.Copy would otherwise impose). A Gogs web-upload on the outer repo calls Repository.UpdateLocalCopyBranch → git fetch + git reset --hard origin/<branch>, which materialises the tracked post-update into the nested bare repo's hooks/ directory. git init --bare only creates *.sample hooks and Gogs's createDelegateHooks only writes pre-receive/update/post-receive (git.ServerSideHooks), so the attacker's post-update is preserved. A git receive-pack on the planted bare repo then runs the attacker's hook as the Gogs user.

Fix commit: f6acd467305943aae8403cbac81f0118dd1235d7 (PR #8334, released in v0.14.3) — UserPath/RepositoryPath now wrap the name with pathutil.Clean, which collapses/neutralises ..; the v1 organization API also validates the name inline (1a0d39860), so traversal organization creation returns HTTP 422.

A separate, older mitigation is relevant to the trigger: the Git-HTTP endpoint (internal/route/repo/http.go, HTTP(), from #7022 / v0.13.0) rejects any request whose path differs from pathutil.Clean ("Request path contains suspicious characters"), and Gogs's SSH serv.go splits the repo path on the first / (so a ../… owner parses as owner ..). Both block a Gogs-HTTP/SSH push to the ../-URL of the traversal-owned repo. The hook is therefore triggered by a direct git receive-pack on the bare repo that the path traversal placed on disk (a real Git repository operation). Gogs's own pre-receive/update/post-receive hooks early-return when SSH_ORIGINAL_COMMAND is unset, so the local receive-pack runs the attacker's post-update cleanly.

Reproduction Steps

1. Self-contained script: bundle/repro/reproduction_steps.sh.
2. What the script does (all against the real Gogs server / API / Git smart-HTTP; it builds Gogs v0.14.2 and v0.14.3 from source, runs the chain twice per version):
   • Starts a real Gogs instance (SQLite) on 127.0.0.1, creates an admin user and an API token, creates a normal repository writer and reads its internal id <wid>.
   • Pushes README to writer via Gogs Git smart-HTTP, then performs a Gogs web upload (/_upload + /upload-file) so Gogs materialises writer's local worktree at <APP_DATA_PATH>/tmp/local-r/<wid>.
   • Pulls/rebases, plants the tracked executable file nested/rce.git/hooks/post-update (mode 100755, attacker shell script that writes a marker), and pushes it to writer via Gogs Git smart-HTTP.
   • Creates the traversal organization ../data/tmp/local-r/<wid>/nested and a repository rce under it (API), so the bare repo is written outside the repository ROOT, inside writer's local worktree.
   • Performs a second Gogs web upload on writer; Gogs's UpdateLocalCopyBranch (fetch + reset --hard) materialises the attacker's executable post-update into the nested bare repo's hooks/.
   • Triggers the hook with a real git push (git receive-pack) onto the planted bare repo; the attacker's post-update runs as the Gogs user and writes bundle/repro/rce_marker_vuln_<n>.txt.
   • For the fixed v0.14.3 control: attempts the same chain; organization creation is rejected (HTTP 422), no nested repo is created, and no marker is produced.
3. Expected evidence of reproduction:
   • bundle/repro/proof_summary.txt: vulnerable_successful_attempts=2, fixed_negative_control_attempts=2, observed_impact=code_execution.
   • bundle/repro/rce_marker_vuln_1.txt / _2.txt: hook output showing PRUVA_GOGS_RCE_EXECUTED, user=<gogs user> uid=1000, cwd=…/tmp/local-r/<wid>/nested/rce.git.
   • bundle/logs/state_vuln_*.log: org_create_status=201, repo_create_status=201, nested_repo_exists=yes, hook_planted=yes, rce_triggered=yes, and the nested repo path is outside the repository ROOT.
   • bundle/logs/state_fixed_*.log: org_create_status=422, nested_repo_exists=no, rce_triggered=no.
   • bundle/repro/runtime_manifest.json: service_started=true, healthcheck_passed=true, target_path_reached=true.

Evidence

• bundle/repro/reproduction_steps.log — full run transcript.
• bundle/repro/proof_summary.txt — verdict counters.
• bundle/repro/runtime_manifest.json — runtime evidence manifest.
• bundle/repro/rce_marker_vuln_1.txt, bundle/repro/rce_marker_vuln_2.txt — proof that the attacker's Git hook executed as the Gogs service user.
• bundle/logs/state_vuln_1.log, bundle/logs/state_vuln_2.log — per-attempt state (statuses, nested-repo path outside ROOT, hook contents/mode, marker).
• bundle/logs/state_fixed_1.log, bundle/logs/state_fixed_2.log — negative control.
• bundle/logs/gogs_vuln_*.log, bundle/logs/http_vuln_*.log, bundle/logs/git_vuln_*.log, bundle/logs/build_vuln.log, bundle/logs/build_fixed.log — server, HTTP, git and build logs.

Key excerpt (vulnerable run, hook execution marker):

PRUVA_GOGS_RCE_EXECUTED
role=vuln idx=1
user=vscode uid=1000 gid=1000
cwd=…/data/tmp/local-r/1/nested/rce.git
Wed Jul  1 14:25:27 UTC 2026

Key excerpt (state, vulnerable): org_create_status=201 repo_create_status=201 nested_repo_exists=yes (outside …/repositories) hook_planted=yes rce_triggered=yes. Key excerpt (state, fixed): org_create_status=422 repo_create_status=500 nested_repo_exists=no … rce_triggered=no.

Environment: Gogs built from source (Go 1.25, tags sqlite cert) at v0.14.2 (commit 5dcb6c64bdf61e38dbdbb941c1d69789c560d0fb) and v0.14.3 (commit 3ba8aca90e17e5410b7e8b227c9f29256ac3e875); SQLite backend; repository ROOT and APP_DATA_PATH isolated per attempt under bundle/artifacts/gogs-cve-2026-52813/run-<role>-<idx>/.

Recommendations / Next Steps

• Upgrade to Gogs 0.14.3 or later, which sanitises owner/repository names via pathutil.Clean and rejects traversal organization creation (HTTP 422).
• Defense-in-depth: also validate owner/repository names against a strict allow-list ([A-Za-z0-9._-]+) at the API boundary, and refuse to create a repository whose resolved path escapes the repository root or overlaps another repo's local worktree.
• Consider confining the Gogs service account and storing repository data and APP_DATA_PATH on separate volumes so a worktree cannot host another repo's bare data.
• Add regression tests that assert UserPath/RepositoryPath reject .. and that organization creation with ../ returns 422.

Additional Notes

• Idempotency: the script removes each attempt's run directory and marker files at the start of run_one, so repeated runs are clean. Verified by running reproduction_steps.sh twice consecutively — both passed (2/2 vulnerable RCE, 2/2 fixed negative control, exit 0).
• Trigger note: the Gogs Git-HTTP endpoint blocks ..-containing URLs (#7022, since v0.13.0) and SSH serv.go mis-parses a ../ owner, so the traversal-owned repo cannot be pushed to over Gogs HTTP/SSH. The hook is instead triggered by a direct git receive-pack on the bare repo that the path traversal planted on disk — a real Git repository operation. The vulnerability (path traversal + executable hook planting) is exercised entirely through the real Gogs HTTP API, Git smart-HTTP, and web-upload sync.
• Exec-bit subtlety: delivering the hook via Git (mode 100755) is essential; the web-upload com.Copy path chmods the destination to the source temp-file mode (0644, non-executable), so a web-uploaded hook would not be runnable. Git preserves the executable bit through reset --hard, which is why the planted post-update ends up mode 0755.