CVE-2026-52813 — Gogs Path Traversal Leading to Git Hooks Remote Code Execution (Defensive Analysis)

Security research / Blue team writeup. This repository does not contain weaponized PoC. Researchers needing reproduction should use the public PoC referenced in the official advisory.

TL;DR

When creating an organization in Gogs, the Web form has AlphaDashDot character validation intercepting /, but the REST API POST /api/v1/user/orgs does not. An attacker submits an organization name containing ../ via the API, bypassing validation and directly reaching os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165), placing the repository directory at an arbitrary filesystem path. Combined with Gogs' web editor temporary working tree (local-r/<repo_id>/), a malicious hooks/update can be placed inside the local checkout of another repository, automatically executed by git → RCE as the git user.

Affected Versions and Remediation

Upgrading is the only complete fix:

# Docker
docker pull gogs/gogs:0.14.3
# Or from source
git checkout v0.14.3 && go build

Temporary mitigations (when upgrading is not possible):

• Disable open registration (app.ini → [service] DISABLE_REGISTRATION = true), downgrading the prerequisite from "unauthorized" to "requires existing account";
• Add WAF rules at the reverse proxy (nginx/Caddy/Traefik) layer to block POST /api/v1/user/orgs and POST /api/v1/org/*/repos request bodies where username / name fields contain .. or / (see detection/);
• Restrict Gogs container write permissions beyond /data/gogs/data/tmp/ (selinux/apparmor).

Root Cause Analysis

1. Validation Asymmetry: Web has it, API does not

Web form (internal/form/org.go, v0.14.2):

type CreateOrg struct {
    OrgName string `binding:"Required;AlphaDashDot;MaxSize(35)"` // regex ^[a-zA-Z0-9._-]+$
}

API (internal/route/api/v1/org/org.go, v0.14.2):

// api.CreateOrgOption (go-gogs-client) binding tag:
type CreateOrgOption struct {
    UserName string `json:"username" binding:"Required"` // ← no AlphaDashDot!
}

→ The username field in POST /api/v1/user/orgs can carry arbitrary characters directly to the DB layer.

2. DB Layer only checks reserved names, not characters

internal/database/users.go:1532 isNameAllowed only intercepts reserved names/prefixes (e.g. admin, -bot), does not validate character set, so ../ passes.

3. Path sink has no sanitization

internal/repoutil/repoutil.go (v0.14.2):

func UserPath(user string) string {
    return filepath.Join(conf.Repository.Root, strings.ToLower(user)) // ← direct concatenation
}

internal/database/org.go:165:

os.MkdirAll(repoutil.UserPath(org.Name), os.ModePerm) // org.Name contains ../ → arbitrary path write

4. Exploiting local-r working tree to land a hook

When Gogs processes Web/API file editing, it checks out the repository into /data/gogs/data/tmp/local-r/<repo_id>/. <repo_id> happens to be the database id of the repository. The attacker:

1. Creates a personal repository writer, resulting in id == n;
2. Via API, creates a traversal organization username = "../../../../data/gogs/data/tmp/local-r/n/nested" → physical directory lands inside writer's working tree;
3. Creates a repository rce-x under that organization → lands in local-r/n/nested/rce-x.git;
4. Clones writer, adds nested/rce-x.git/hooks/update as a normal file, commits and pushes (it lands inside writer's working tree);
5. Triggers a file operation via API on writer → Gogs runs git in local-r/n/ → git executes hooks/update → RCE.

Key point: the malicious hook is introduced as normal repository content via a normal push, no need for ENABLE_GIT_HOOKS configuration — this is what distinguishes it from the "traditional git hooks abuse" approach.

Detailed patch diff analysis in patch/ANALYSIS.md.

Detection

Complete rules in detection/:

• Sigma rules: detection/sigma/ — covers attack attempts (API requests containing ../) and successful exploitation (filesystem landing)
• SIEM queries: detection/queries.md — Splunk / Elastic / Kibana / Loki
• IOCs: detection/iocs.md — filesystem traces, log signatures, username patterns

The two most critical ones:

1. WAF / reverse proxy layer block: POST /api/v1/user/orgs and POST /api/v1/org/*/repos JSON body where username/name fields contain .. or /.
2. Filesystem inspection: unexpected subdirectories under /data/gogs/data/tmp/local-r/*/ (e.g., nested/, rce-*.git, hooks/update).

Defensive Tooling

• tools/check_version.py — Non-invasive version scanner: checks whether a Gogs instance is < 0.14.3 via GET /api/v1/version, supports batch scanning, CSV output, suitable for asset inventory.

This repository does not provide weaponized exploitation tools. For reproduction, use the public PoC referenced in the official advisory, and only in isolated self-hosted environments.

Lab Environment

detection/ rules need validation on an affected Gogs instance, lab/docker-compose.yml provides an isolated Gogs 0.14.2 environment for blue teams to test detection rule hits. Do not expose to the public internet, local use only.

Timeline

References

• Official advisory: https://github.com/gogs/gogs/security/advisories/GHSA-c39w-43gm-34h5
• Fix PR: https://github.com/gogs/gogs/pull/8334
• OSV: https://osv.dev/vulnerability/CVE-2026-52813
• Gogs 0.14.3 release: https://github.com/gogs/gogs/releases/tag/v0.14.3

⚠️ About the "gitrebase parameter injection" Misinformation

Some online sources describe this CVE as "Gogs gitrebase parameter injection remote code execution" — that is incorrect. This vulnerability has nothing to do with git rebase / gitrebase; the root cause is API path traversal. This document analyzes the real vulnerability.

License

MIT — see LICENSE.