Critical Gogs RCE Flaw Enables Authenticated Users to Execute Arbitrary Code

A critical remote code execution vulnerability in Gogs, a widely-deployed open-source Git service, allows any authenticated user to execute arbitrary code on the server. Rated 9.4 on the CVSS scale, the flaw remains unpatched 72 days after Rapid7 disclosed it to the maintainer on March 17, 2026. The vulnerability requires only basic user authentication and exploits the git rebase merge operation through specially crafted branch names.

Attack Vector and Exploitation Requirements

The vulnerability exploits how Gogs handles the 'Rebase before merging' operation when processing pull requests. Security researcher Jonah Burgess from Rapid7 discovered that attackers can inject the --exec flag into git rebase commands by creating pull requests with malicious branch names. The --exec flag allows shell commands to execute after each commit is replayed during the rebase process.

What makes this vulnerability particularly dangerous is its minimal barrier to exploitation. An unauthenticated threat actor only needs to create an account and repository on any default-configured Gogs instance. Any registered user who creates a repository automatically becomes its owner, and enabling rebase merging requires a single toggle in settings. The entire exploit chain operates without interaction from other users or administrative privileges.

Technical Breakdown of the Exploit

Git rebasing is a standard operation that takes a sequence of commits from one feature branch and replays them on another base branch to create a linear project history. Unlike git merge, which creates a merge commit, git rebase rewrites project history by creating new commits for each original commit. The git rebase command accepts shell commands via the --exec flag, executing them after each commit replay.

Gogs fails to properly sanitize branch names before passing them to git rebase operations. By crafting a branch name that includes --exec followed by arbitrary shell commands, attackers can inject code that executes with the privileges of the Gogs server process. This command injection occurs during the merge operation when repository owners or maintainers attempt to rebase and merge pull requests.

Multiple Attack Scenarios

Rapid7 identified three distinct exploitation scenarios depending on the target instance's configuration:

• Default configuration: Attacker creates an account, creates a repository (becoming automatic owner), enables rebase merging in settings, and exploits the vulnerability without further user interaction
• Write access scenario: User with write access to any repository where rebase is already enabled can exploit the flaw directly for immediate code execution
• Restricted registration: On instances where repository creation is limited, attackers require write access to existing repositories with rebase merging enabled

Impact and Cross-Tenant Implications

Successful exploitation grants attackers complete server compromise. Threat actors can access every repository on the instance, regardless of privacy settings or organizational boundaries. This includes dumping stored credentials, accessing SSH keys, and reading deployment secrets. The attacker gains the ability to tamper with any hosted repository's code, potentially injecting backdoors or malicious commits into production codebases.

The cross-tenant data breach scenario poses severe risks for shared Gogs instances. Organizations hosting multiple teams or customers on a single Gogs server face the prospect of one compromised user account leading to complete data exposure across all tenants. Attackers can pivot to other network-accessible systems using compromised credentials, expanding their foothold beyond the Git server itself.

Immediate Mitigation Actions

In the absence of an official patch, organizations must implement defensive configurations immediately. Rapid7 recommends three critical mitigations:

• Disable user registration by setting DISABLE_REGISTRATION = true in app.ini to prevent untrusted actors from creating accounts
• Restrict repository creation by setting MAX_CREATION_LIMIT = 0 in app.ini, preventing users from creating exploit repositories
• Audit and disable rebase merge settings across all existing repositories, reverting to standard merge operations until patches become available

Organizations should immediately inventory all Gogs deployments, including those on internal networks and behind VPNs. The 1,141 internet-facing instances represent only a fraction of the vulnerable attack surface. Review server logs for HTTP 500 errors coinciding with repository creation or merge operations, as these may indicate exploitation attempts. Monitor for unauthorized repository creation, unexpected merge operations, and anomalous process execution on Gogs servers.

Detection and Forensic Considerations

The vulnerability's stealth characteristics complicate detection efforts. When attackers create and delete temporary repositories, the primary forensic artifact is an HTTP 500 error in server logs. Exploits targeting existing repositories leave more evidence, including merge operation logs, commit histories with suspicious branch names, and potentially process execution logs if system-level monitoring is enabled.

Security teams should implement enhanced monitoring for Gogs instances, including file integrity monitoring on the server, network traffic analysis for unexpected outbound connections, and process execution monitoring to detect shell commands spawned by the Gogs process. Review repository access logs for unusual patterns, particularly users accessing repositories outside their normal scope immediately following merge operations.

Strategic Recommendations

This vulnerability highlights the risks of self-hosted Git services in critical infrastructure. Organizations should evaluate their Gogs deployment strategy, considering whether the platform remains appropriate for their security posture. The 72-day window without patches raises questions about the project's maintenance status and responsiveness to security issues.

For organizations dependent on Gogs, implement defense-in-depth controls including network segmentation to isolate Git servers, least-privilege access policies limiting repository creation and write access, and comprehensive logging with SIEM integration for anomaly detection. Consider migrating to alternative self-hosted Git platforms with more active security maintenance or evaluating managed Git services for non-sensitive repositories. Until patches emerge, treat all Gogs instances as compromised and validate the integrity of hosted codebases through independent source control verification.