New Rule - Gogs Rebase RCE Argument Injection via Git --exec Flag (Linux)

[WRG-11]

New Sigma Rule: Gogs Rebase RCE Argument Injection

Vulnerability

Gogs (the self-hosted Git service) passes a pull request's base branch name to
git rebase without a -- separator. A branch named --exec=<cmd> is
interpreted by git as the --exec flag, executing arbitrary commands as the
Gogs server user. The flaw requires only an authenticated account; on instances
with open registration that means any user. A public Metasploit module exists
(multi/http/gogs_rebase_rce). The issue is unpatched as of the Rapid7
disclosure (2026-03-17).

• CVSSv4: 9.4 (Critical)
• CWE-88: Argument Injection
• Disclosure: https://www.rapid7.com/blog/post/ve-authenticated-rce-via-argument-injection-gogs-unfixed/
• Coverage: https://thehackernews.com/2026/05/critical-gogs-rce-vulnerability-lets.html

Detection Logic

The rule uses three concurrent conditions:

1. Image: /git - the git binary is executing
2. CommandLine contains rebase AND (--exec OR -x) - exec injection is present
3. ParentImage: /gogs - the rebase was launched by the Gogs server

Why the parent scope is the 0-FP discriminator: git rebase --exec is a
legitimate developer feature (e.g. git rebase --exec "make test"). A bare
exec-flag selection would match benign developer activity. In the exploit, the
rebase is always launched by the Gogs server process; a developer or CI runner
launching the same command has a shell, IDE, or runner as the parent. The rule
fires only when all three conditions are true simultaneously.

Known limitation

If a Gogs deployment uses a shell intermediary (gogs -> sh -c "git rebase --exec=<cmd>"),
the git parent is /sh, not /gogs, and this rule does not fire. This is a
coverage gap, not a false positive.

Testing

Rule passes sigma check with tests/sigma_cli_conf.yml validation config:
0 errors, 0 condition errors, 0 issues. Also passes the legacy tests/test_rules.py suite (11/11).

[github-actions]

Welcome 👋

It looks like this is your first pull request on the Sigma rules repository!

Please make sure to read the SigmaHQ conventions to make sure your contribution is adhering to best practices and has all the necessary elements in place for a successful approval.

Thanks again, and welcome to the Sigma community! 😃

[swachchhanda000]

Hi @WRG-11,

Thanks for your submission. Before we proceed with the review, here are a few suggestions:

• Rules targeting new CVEs, malware, or APTs, are generally tracked as Emerging Threat rules and have a dedicated space in the repository: https://github.com/SigmaHQ/sigma/tree/master/rules-emerging-threats
• Since a public PoC is available in Metasploit, it would be helpful if you could execute it and provide real logs. That would make it much easier to verify the detection logic instead of relying on assumptions. This would also strengthen the PR significantly and improve its chances of being merged compared to a long AI-generated summary or description.

[WRG-11]

Thanks @swachchhanda000, both make sense.

1. Moved it to rules-emerging-threats/2026/Exploits/CVE-2026-52806/ (the issue was assigned
   CVE-2026-52806 and fixed in Gogs 0.14.3), added the detection.emerging-threats and cve.2026-52806
   tags, and set status: experimental.

2. Good point on the logs. I'll run the public Metasploit module against a self-hosted Gogs 0.14.2
   instance and attach the real process_creation events (auditd / Sysmon for Linux) showing the injected
   --exec git rebase under the gogs parent process, so the detection can be verified against actual telemetry.