Critical Gogs RCE Flaw Remains Unpatched, Metasploit Module Publicly Released
#Vulnerabilities

Critical Gogs RCE Flaw Remains Unpatched, Metasploit Module Publicly Released

Hardware Reporter
4 min read

A CVE‑2026‑xxxx remote‑code‑execution bug in the open‑source Git service Gogs can be triggered by any authenticated user on a default install. The flaw, reported in March, still has no official fix, and a Metasploit exploit module is now available, raising the risk of active exploitation.

Critical Gogs RCE Flaw Remains Unpatched, Metasploit Module Publicly Released

Featured image

Date: 29 May 2026 | Author: Jessica Lyons


What happened

Rapid7 researcher Jonah Burgess disclosed a critical remote‑code‑execution (RCE) vulnerability in Gogs (Git Object Storage) on 17 March 2026 (GHSA‑qf6p‑p7ww‑cwr9). The issue affects every supported platform – Linux, Windows and macOS – and every deployment method, from Docker images to binary tarballs. Despite an initial acknowledgement on 28 March, the Gogs maintainers have not responded, and no official patch exists. On 29 May a public Metasploit module (exploit/windows/http/gogs_rce) was released, meaning attackers can now automate exploitation with a single command.


Why it matters

  • Any authenticated user can trigger the bug; no admin or repository‑owner rights are required.
  • Successful exploitation gives the attacker a full shell on the host, allowing credential theft, MFA secret exfiltration and repository tampering – a perfect vector for supply‑chain attacks.
  • The vulnerability lives in the Merge() function of internal/database/pull.go. When the Rebase before merging option is enabled, the base‑branch name is passed directly to git rebase without a -- separator. An attacker can craft a branch name such as --exec=touch${IFS}/tmp/rce_proof which Git interprets as an --exec flag and runs the payload.
  • Windows installations receive a slightly different payload format, but the Metasploit module abstracts the platform differences, delivering a cross‑platform exploit.

Technical breakdown

Component Vulnerable code Trigger Effect
internal/database/pull.goMerge() git rebase $baseBranch (no -- separator) Authenticated user creates a PR with rebase enabled and a malicious branch name Git executes arbitrary command supplied in branch name
Configuration app.ini defaults allow registration and repo creation No hardening out of the box Attack surface includes newly registered accounts

Exploit flow (Linux example)

  1. Attacker registers an account (or uses any existing credential).
  2. Enables Rebase before merging on a repository they can write to.
  3. Creates a branch named --exec=touch${IFS}/tmp/rce_proof.
  4. Opens a pull request targeting that branch.
  5. Gogs invokes git rebase --exec=touch /tmp/rce_proof <target>.
  6. The touch command runs as the Gogs process user, creating a file that proves code execution. A more malicious payload could download a web‑shell or dump SSH keys.

On Windows the payload uses cmd /c syntax, but the underlying injection vector is identical.


Mitigation checklist

Until a fix lands, administrators should apply the following hardening steps. All settings are edited in custom/conf/app.ini and require a service restart.

Step Setting Recommended value Impact
1 DISABLE_REGISTRATION true Prevents new untrusted accounts from being created
2 MAX_CREATION_LIMIT 0 Stops users from creating their own repositories
3 Rebase merge Disable via UI Settings → Advanced → Rebase before merging Removes the vulnerable code path
4 Network segmentation Place Gogs behind an internal firewall, expose only required ports (SSH, HTTP/HTTPS) Limits exposure to internal attackers
5 Monitoring Enable audit logging, watch for git rebase executions with --exec in process lists Early detection of attempted exploitation

Note: The above controls stop the most common attack vector but do not protect a malicious user who already has write access to a repository. In that scenario the only reliable defense is a patched binary.


Community response

  • The public Metasploit module is available in the 5.0 release of Metasploit Framework: use exploit/multi/http/gogs_rce. The module automatically detects the target OS, crafts the appropriate branch name and triggers the rebase flow.
  • Rapid7 submitted a pull request with a tentative fix – sanitising the branch name and inserting the required -- separator – on 29 May. The PR is awaiting review; no maintainer has merged it yet.
  • DigitalOcean, a corporate sponsor of Gogs, has not replied to media inquiries regarding a timeline for a fix.

What to watch next

  • In‑the‑wild exploitation – the Metasploit module lowers the barrier to attack, so watch for unusual git rebase processes in host logs and for newly created files in /tmp or %TEMP%.
  • Patch release – the Gogs project historically moves slowly on security updates. Keep an eye on the official GitHub issue tracker and the mailing list for any merge of the community PR.
  • Alternative self‑hosted Git services – if you cannot wait for a fix, consider migrating to Gitea or Forgejo, both of which have already patched the rebase handling logic.


Bottom line: The Gogs RCE bug is fully exploitable on default installations, a public exploit is now available, and the maintainers have not yet delivered a patch. Administrators should lock down registration, disable rebase merges and monitor for suspicious rebase activity while waiting for an upstream fix.

Comments

Loading comments...