New Gogs zero-day flaw lets hackers get remote code execution

# Critical Gogs Zero-Day Enables Remote Code Execution on 2,400+ Exposed Servers

An unpatched zero-day vulnerability in Gogs, a popular self-hosted Git service, exposes thousands of Internet-facing instances to remote code execution (RCE) attacks. The critical-severity flaw requires only basic user privileges to exploit and can be weaponized within minutes on servers running default configurations—which is the majority of exposed instances.

## The Threat

Security researchers at Rapid7 have disclosed a critical argument injection vulnerability in Gogs that allows attackers to execute arbitrary code as the Git service process user. The flaw, discovered by senior security researcher Jonah Burges, has not yet been assigned a CVE identifier and remains unpatched as of May 28, 2026.

Affected versions:

The vulnerability can be exploited through a malicious branch name in a pull request, injecting the —exec flag into the git rebase command during the "Rebase before merging" merge operation. Once triggered, the attacker gains code execution capabilities on the underlying server.

Scope of exposure:

## Background and Context

Gogs (Go Git Service) is a lightweight, self-hosted Git platform designed as an alternative to GitHub Enterprise and GitLab. Written in Go, it's popular for organizations requiring on-premises source code management. Its simplicity and low resource requirements make it attractive for smaller teams and embedded deployments—but also create widespread misconfigurations.

Default Insecurity:

The vulnerability is particularly dangerous because Gogs ships with two insecure defaults enabled:

This combination means an unauthenticated attacker can:

1. Register an account on any default-configured instance

2. Create a repository immediately

3. Enable rebase merging in settings

4. Exploit the vulnerability without any interaction from other users

"The entire exploit chain can be operated without interaction from any other user," Burges noted, highlighting how low the barrier to entry is.

## Technical Details

### The Exploitation Chain

The vulnerability operates through the Gogs merge operation, specifically the Merge() function, which has never been patched despite similar flaws being addressed in prior releases.

Attack steps:

1. Account Creation: Attacker registers a free account on the target instance (default settings allow this)

2. Repository Setup: Creates a new repository and configures it with rebase merging enabled

3. Malicious Branch: Creates a pull request with a specially crafted branch name containing argument injection payloads

4. Code Execution: When the "Rebase before merging" action is triggered, the injected —exec flag gets passed to git rebase, executing arbitrary commands

5. System Compromise: Commands execute as the Gogs process user, providing full access to the server

### Similar Vulnerabilities in Gogs History

This is not the first argument injection flaw in Gogs. Burges noted the vulnerability is similar to previously patched issues:

However, the current flaw exploits a different code path that was never secured, suggesting that Gogs' development team may not have implemented a systematic patch to prevent argument injection across all Git operations.

### Recent History: CVE-2025-8110

In early December 2025, Gogs patched CVE-2025-8110, another critical RCE vulnerability that was actively exploited to compromise hundreds of servers. That timeline is instructive:

| Date | Event |

|------|-------|

| July 2025 | Wiz Research discovers CVE-2025-8110 during investigation of compromised server |

| July 17, 2025 | Vulnerability reported to Gogs maintainers |

| October 30, 2025 | Gogs acknowledges the report (3+ months delay) |

| January 2026 | Patch released for CVE-2025-8110 |

| January 12, 2026 | CISA confirms active exploitation and adds to KEV catalog |

The current zero-day follows a similar pattern of delayed response and unpatched code paths.

## Exploitation Impact

A successful compromise grants attackers the ability to:

## Implications for Organizations

### Immediate Risk

Organizations running Internet-facing Gogs instances with default configurations are at extreme risk. The exploit requires minimal technical skill and can be fully automated. An attacker with basic knowledge of Git operations can compromise a server in minutes.

High-risk sectors:

### The Default Configuration Problem

Gogs' insecure defaults exemplify a broader industry problem: deploying services without security-first configuration. Open registration made sense for public Git hosting platforms in 2014, but modern threat landscapes demand authentication-first approaches.

"Many of these instances are configured with 'Open Registration' enabled by default, creating a massive attack surface," Wiz researchers noted after discovering CVE-2025-8110. This remains true for the new zero-day.

## Recommendations

### For Gogs Administrators (Immediate Actions)

1. Disable Open Registration

```

DISABLE_REGISTRATION = true

```

Require administrators to manually create user accounts or use LDAP/OAuth integration.

2. Restrict Repository Creation

```

MAX_CREATION_LIMIT = 10 # Or appropriate limit for your organization

```

Limit how many repositories each user can create.

3. Isolate Instances

- Move Gogs behind a VPN or firewall

- Require authentication at the network perimeter

- Disable public Internet access if not necessary

4. Monitor for Exploitation

- Review recent pull requests with unusual branch names

- Check git rebase operations in logs

- Monitor for unexpected process execution from the Gogs user

5. Prepare for Patching

- Monitor the Gogs GitHub repository for patches

- Test patches in a staging environment before production deployment

- Plan for downtime if patches require service restarts

### For Organizations Evaluating Gogs

Consider whether Gogs' security posture aligns with your requirements. GitLab and Gitea (an actively maintained Gogs fork) receive more frequent security updates and have clearer patch timelines.

### For the Security Community

The 73-day gap between the discovery date (March 17) and the current disclosure (May 28) raises questions about coordinated disclosure practices. Responsible disclosure timelines typically expect patches within 30-45 days. The Gogs maintainers' lack of response suggests either insufficient resources or prioritization challenges.

## HackWire Analysis

This vulnerability represents a systemic failure at three levels: insecure defaults, delayed patching, and insufficient security awareness in deployment practices.

Why this matters now: Gogs occupies a critical but overlooked niche—it's trusted by teams who explicitly chose self-hosting to maintain control, yet often deployed by administrators without security expertise. The combination of open registration, unlimited repo creation, and unpatched code creates a nearly frictionless attack surface. Unlike a supply chain vulnerability affecting millions through a single vendor, each compromised Gogs instance is a targeted organizational breach with access to source code, credentials, and internal infrastructure.

Pattern recognition: This is the second critical RCE in Gogs in less than a year. CVE-2025-8110 followed an identical pattern: months of delay between discovery and patch, exploitation in the wild, and deployment on thousands of vulnerable instances before fixes became available. The reappearance of argument injection flaws—a class of vulnerability that's been well-understood since the early 2000s—suggests the Gogs codebase lacks systematic input validation across Git operations.

The hidden risk: Most coverage focuses on exposed instances, but the real danger is in semi-exposed ones—Gogs installations behind corporate firewalls or VPNs that developers access over SSL. These aren't tracked by Shadowserver or Shodan, but they host proprietary code and serve teams of 5-500 developers. A breach here leaks custom applications, infrastructure patterns, and internal authentication mechanisms. For technology companies, this is equivalent to a full source code leak.

Concrete next steps: Administrators should immediately disable open registration and repository creation limits, even if it inconveniences users. The risk of a five-minute account creation process is far outweighed by the certainty of compromise if defaults remain. Teams should also stop waiting for patches from Gogs maintainers and prepare migration plans to actively maintained alternatives like Gitea or GitLab. The 73-day silence suggests Gogs may no longer be a reliable platform for security-critical deployments.

— HackWire Editorial

## Related Coverage