Critical Gogs RCE Vulnerability Lets Any Authenticated User Execute Arbitrary Code

Rapid7 Discloses Critical RCE in Gogs Self-Hosted Git Service

Security researchers at Rapid7 have disclosed a critical remote code execution vulnerability in Gogs, the widely used open-source self-hosted Git service, rated CVSS 9.4. The flaw enables any authenticated user to execute arbitrary code on the server under certain conditions — representing a severe risk for organizations using Gogs to host internal source code repositories.

Gogs is the underlying platform for many self-managed Git deployments across development teams, open-source projects, and enterprises that prefer to host their own Git infrastructure outside of cloud platforms such as GitHub or GitLab.

What Is Gogs?

Gogs (Go Git Service) is a lightweight, self-hosted Git platform written in Go, designed to be simple to deploy and run on minimal hardware. Key characteristics that make it widely adopted — and that amplify this vulnerability's impact:

• Lightweight and self-contained — a single binary with no external runtime dependencies
• Easy deployment — runs on Linux, macOS, Windows, ARM, and even Raspberry Pi
• Broad deployment — used by individuals, SMBs, universities, and open-source projects
• Self-managed patching — no automatic vendor-pushed updates; operators must patch manually
• Often internet-facing — many organizations expose Gogs publicly for remote collaboration

The self-managed update model is particularly relevant: organizations running Gogs are entirely responsible for tracking and applying security patches, making slow patch cycles a persistent risk.

The Vulnerability

Rapid7's research identified a security flaw that allows an authenticated Gogs user — even one with a standard, low-privilege account — to execute arbitrary code on the server under certain conditions. The vulnerability is rated CVSS 9.4 (Critical).

While the flaw requires authentication, the bar is low: any user with a Gogs account can trigger the vulnerability. In environments where user registration is open or Gogs accounts are broadly provisioned, this effectively lowers the barrier to near-zero for motivated attackers.

The CVSS 9.4 score reflects the high impact on confidentiality, integrity, and availability of the affected system — all three are rated High — combined with the low complexity of the attack and the minimal privileges required.

Why CVSS 9.4 With Authentication Required?

The CVSS scoring system does not require an unauthenticated attack vector to reach Critical severity. In this case, the score reflects:

• Attack Complexity: Low — once authenticated, exploitation is straightforward
• Privileges Required: Low — any standard account suffices, not just admins
• User Interaction: None — no victim interaction is required
• Scope: Changed — the vulnerability crosses security boundaries beyond the vulnerable component
• Impact: High / High / High — full compromise of confidentiality, integrity, and availability

A CVSS 9.4 with low-privilege authentication is functionally equivalent to unauthenticated RCE in environments with open registration or any level of external user access.

Impact on Affected Organizations

Source Code Exposure

The immediate risk is total source code exposure. A Gogs instance typically hosts an organization's entire codebase. An attacker exploiting this flaw gains:

• Read access to all repositories on the Gogs instance
• Access to commit history, branch configurations, and tags
• Access to repository hooks, webhooks, and deploy key configurations
• Secrets inadvertently committed to repositories (API keys, passwords, tokens)

CI/CD Pipeline Compromise

Many Gogs deployments integrate with CI/CD systems — Jenkins, Drone, Woodpecker, or custom webhook-driven pipelines. Remote code execution on the Gogs server creates a direct path to:

• Inject malicious code into the build pipeline via manipulated repository content
• Steal build secrets including signing keys, artifact upload credentials, and deployment tokens
• Trigger unauthorized builds or modify build scripts before legitimate jobs run

This transforms a Gogs server compromise into a software supply chain attack against anything built from code hosted on that instance.

Credential and Token Theft

Gogs stores a significant volume of sensitive authentication material:

• SSH deploy keys for automated repository access
• Webhook secrets for CI/CD integration
• OAuth application credentials if Goobi is acting as an OAuth provider
• User password hashes and session tokens from the underlying database
• SMTP credentials if email notifications are configured

Comparison With the Co-Disclosed Gogs Zero-Day

Rapid7's CVSS 9.4 disclosure coincides with a separately disclosed unauthenticated zero-day in Gogs that was reported concurrently. While the two vulnerabilities affect the same platform, they are distinct:

Organizations running Gogs face two concurrent critical vulnerabilities affecting the same platform, making immediate action essential.

Mitigation Steps

1. Restrict Account Registration

If Gogs is configured to allow open registration, disable it immediately:

• Navigate to Site Administration → Users settings in Gogs
• Disable Allow Users to Register or restrict registration to invitation-only
• Remove any untrusted accounts that may have been created

This does not eliminate the vulnerability but raises the bar for unauthenticated external attackers.

2. Remove Gogs From the Public Internet

Place the Gogs instance behind a VPN or zero-trust access solution:

# If running behind Nginx, add authentication before proxying to Gogs
# Use Authentik, Authelia, or oauth2-proxy in front of the Gogs upstream
location / {
    auth_request /auth;
    proxy_pass http://gogs:3000;
}

Only users who can authenticate to the access proxy should be able to reach Gogs at all.

3. Monitor for Unusual Activity

Until patched, watch for exploitation indicators:

• Unexpected process spawning from the Gogs binary
• Unusual file creation or modification in Gogs data directories
• Outbound network connections from the Gogs process to external hosts
• Repository changes not attributable to known user activity
• New SSH keys added to repositories or user accounts
• Unexpected Gogs admin account creation events

4. Apply Patches When Available

Monitor the official Gogs repository for a security release:

• Check github.com/gogs/gogs/releases for new releases
• Subscribe to the Gogs repository's watch/notifications for release events
• Apply any released patch on an emergency timeline given the CVSS 9.4 severity

Considering Migration

This second critical vulnerability disclosure in a short period raises the question of whether organizations relying on Gogs should evaluate migration to a more actively maintained platform. Options include:

Migration is not an immediate mitigation and should be evaluated as a longer-term project, but the pattern of critical vulnerabilities in Gogs warrants planning.

Key Takeaways

• Rapid7 disclosed a CVSS 9.4 critical RCE in Gogs — exploitable by any authenticated user
• Combined with a concurrent unauthenticated zero-day, Gogs currently has two open critical issues
• Organizations hosting internal source code on Gogs face supply chain risk if either vulnerability is exploited
• Immediate mitigations: restrict registration, remove from public internet, monitor for exploitation
• Apply the upstream patch as soon as a security release is available

Sources: The Hacker News, Rapid7