Critical Gogs RCE Vulnerability Lets Any Authenticated User Execute Arbitrary Code

# Critical Gogs RCE Lets Authenticated Users Execute Arbitrary Code on Self-Hosted Git Servers

A critical remote code execution vulnerability in Gogs, a widely-deployed self-hosted Git service, exposes thousands of organizations to arbitrary code execution from any authenticated user. The flaw, discovered by researcher Jonah Burgess and confirmed by Rapid7, has remained unpatched for more than two months, leaving vulnerable instances exposed to server compromise, credential theft, and cross-tenant data breaches.

## The Threat

Gogs is a lightweight, self-hosted Git service popular among organizations wanting to maintain code repositories on internal infrastructure. The vulnerability exploits how Gogs handles the Git rebase operation—specifically, the --exec flag that allows custom shell commands to run after each commit is replayed. When an authenticated user creates a pull request with a specially crafted branch name, they can inject the --exec flag directly into the rebase command, causing arbitrary code execution on the server with the privileges of the Gogs process.

The attack requires minimal setup. An attacker needs only a valid account and either permission to create a new repository or write access to an existing repository where rebase merging is enabled. Creating a repository on a default-configured Gogs instance is trivial—any registered user automatically becomes the owner of their own repo. Enabling rebase merging is a single toggle in the settings. From this position, the entire exploit chain can execute without interaction from any other user.

The implications are severe for self-hosted environments. Successful exploitation grants an attacker the ability to breach the entire server, access every repository on the instance, dump stored credentials, pivot to other network-accessible systems, and modify code across any hosted project. In multi-tenant scenarios where a shared Gogs instance hosts repositories for multiple organizations, the vulnerability enables cross-tenant data breaches, allowing an attacker to read private repositories belonging to other users on the same server. This transforms a single-user account compromise into a potential organization-wide incident.

## Severity and Impact

| Attribute | Value |

|---|---|

| CVSS Score | 9.4 (Critical) |

| CVE Identifier | Not assigned |

| Vulnerability Type | Improper Input Neutralization / Command Injection (CWE-78) |

| Attack Vector | Network |

| Attack Complexity | Low |

| Privileges Required | Low (authenticated user) |

| User Interaction | None |

| Scope | Changed (can affect other systems) |

| Confidentiality Impact | High |

| Integrity Impact | High |

| Availability Impact | High |

| Affected Platforms | Windows, Linux, macOS |

## Affected Products

Gogs (self-hosted Git service)

Organizations running Gogs on Windows, Linux, or macOS environments are potentially affected. The vulnerability does not require a specific version threshold; the flaw affects current deployments.

## Mitigations

Organizations running Gogs instances should implement the following controls immediately:

Configuration Hardening (in app.ini):

Operational Controls:

Detection and Response:

Patch availability has not yet been announced. Organizations should monitor the Gogs GitHub repository and official channels for security updates.

## References

---

## HackWire Analysis

This vulnerability exemplifies a critical blind spot in self-hosted infrastructure security: the assumption that internal tools require less rigorous threat modeling than external-facing systems. Gogs is deployed across thousands of organizations specifically because it keeps code repositories on-premise, yet this architectural choice often correlates with *reduced* security investment, not increased.

The 71-day gap between disclosure (March 17) and public awareness (late May) is concerning. Self-hosted infrastructure operators frequently operate without the coordinated disclosure infrastructure that major vendors maintain. This delay compounds the risk—attackers now have months of exploitation opportunity against patched-unaware organizations.

The CVSS 9.4 score understates the real-world impact. The vulnerability combines three amplifying factors: (1) authentication is trivial on open instances, (2) exploitation is fully automated (Rapid7 released a Metasploit module), and (3) the blast radius includes all repositories on a shared instance. A single compromised account on a team's Gogs server can expose code across the entire organization.

Critically, this vulnerability belongs to a recurring pattern in Git hosting. Historical RCE issues in GitLab, Gitea, and other self-hosted platforms share this signature: command injection via repository metadata during merge operations. Organizations standardizing on *any* self-hosted Git solution should treat command-injection-in-git-operations as a standing threat model, not a one-time patch cycle.

For defenders: this advisory should trigger an immediate audit cycle. Search your Gogs instances for suspicious branch names. Check for unauthorized repositories created in the past three months. If you're running instances on the public internet, assume compromise unless you can prove otherwise. The workarounds (disable registration, disable repo creation) are severe but necessary until patching is available.

— HackWire Editorial

---

## Related Coverage