Researchers have discovered a zero-day vulnerability in Gogs, the widely used self-hosted Git repository management platform, that may allow authenticated users to escalate their privileges on vulnerable servers by leveraging this vulnerability to execute remote code. 

In addition to affecting current Gogs releases, this vulnerability is classified as a critical argument injection weakness that poses a particular risk to distributed software development and collaboration deployments that are Internet-accessible. As a result of security analysis, the attack can be carried out without administrative privileges and, under default configurations, the attacker may only need a standard user account to compromise the underlying host. 

The finding highlights the fact that seemingly routine source code management operations can become high-impact attack vectors when exploitable flaws intersect with permissive default settings and exposed development infrastructure, which has not been officially patched at the time of disclosure. Due to the close alignment between the attack path and Gogs' default deployment behaviour, the exposure becomes especially significant. 

A Rapid7 researcher stated that open registration of users and the creation of unrestricted repositories enable an external actor to establish the necessary conditions for exploitation without requiring privileged access or assistance from other users. An application-wide flaw exists in the application's handling of repository merge operations. If the branch name is specially crafted, malicious arguments can be injected into the git rebase process during the "Rebase before merging" workflow by using a specially crafted branch name. 

By abusing Git's --exec parameter, an attacker can force arbitrary shell commands to run on the host system under the security context of the Gogs service account. As researchers noted, the consequences of the compromise extend far beyond a single repository compromise, allowing threat actors to access private repositories belonging to other users, extract sensitive credentials such as password hashes, API tokens, SSH keys, multi-factor authentication secrets, and move laterally across connected systems, as well as alter source code stored on the system. 

While Burgess indicates that Gogs has addressed several argument injection vulnerabilities in recent years, this newly discovered vulnerability stems from a different code path within the Merge() function, which was not addressed. Moreover, users with write permissions in repositories with rebase merging are also at risk of exploiting this vulnerability, while environments which restrict repository creation remain vulnerable if attackers can obtain write access to qualifying projects. 

While the flaw was reported to the maintainer in March 2026, it remains unpatched as of the date of publication, making deployments across Windows, Linux, and macOS vulnerable to exploitation. Approximately 1,100 Gogs instances are currently exposed to the internet, according to Rapid7, but the true number is likely to be substantially greater due to the prevalence of deployments that operate behind VPNs and internal enterprise networks.

Additionally, the disclosure has brought to the vendor's attention concerns relating to its response timeframe. In March 2026, Burgess reported the vulnerability to the Gogs maintainers and received an acknowledgement on March 28, but no security update has been released since then. Given the platform's existing exposure footprint, this delay is particularly noteworthy. 

Data from Shadowserver indicates that more than 2,400 publicly accessible Gogs instances are currently located in Asia and Europe, with the highest concentrations occurring in the region, while Shodan indexes over 1,000 internet-facing systems that exhibit identifiable Gogs signatures. An incident of this type is reminiscent of one that occurred with CVE-2025-8110, another remote code execution vulnerability that was exploited by hackers before patches were available. 

A vulnerability discovered by Wiz Research during an investigation into a compromised Gogs deployment ultimately led to the U.S. Government's Cybersecurity and Infrastructure Security Agency (CISA), which classified it as actively exploited and directed federal agencies to secure affected systems, resulting in a significant threat model. 

In addition, this new flaw undermines the trust boundaries underlying shared Git hosting environments, making it a similar serious threat model. It is common for businesses, universities, and development teams to deploy multi-user software environments, where a single, authenticated account can control the underlying server infrastructure without having to gain access to another user's repository. 

If code execution is achieved, an attacker will be able to access all repository files hosted on the instance, extract authentication credentials stored within the backend databases, enter adjacent network resources, and manipulate source code on the file system. 

Gogs service accounts usually maintain unrestricted read and write rights across repositories that are stored under the same repository root; therefore, malicious modifications can bypass platform-level audit mechanisms and are difficult to identify in environments where commit-signing enforcement does not exist. It was also noted that exploitation can be highly practical and automated using publicly available tools, enabling attacks to be carried out within seconds with minimal forensic evidence remaining. 

Gogs' implementation of the "Rebase before merging" feature has resulted in the issue, as it internally invokes the git rebase command to create a linear project history by replaying commits. With the --exec parameter, Git executes shell commands after each replayed commit, creating the exploitation primitive when malicious input is incorrectly handled. 

While the rebase merge functionality is disabled by default, the repository can enable the feature through the project owner's settings, and new repositories are automatically assigned ownership to their creators, ensuring that abuse does not occur. Despite deployments that restrict repository creation, vulnerable code paths can still be exploited to execute remote commands by users who have access to repositories that support rebase merging.

Newly disclosed vulnerabilities in development platforms such as Gogs serve as a timely reminder that these platforms can magnify the impact of a single security weakness across entire software ecosystems. Considering the lack of a patch and the requirement for limited user privileges to exploit Gogs in common deployment configurations, organisations relying on Gogs should carefully evaluate repository permissions, disable unnecessary registration and repository creation features, and closely monitor merging activity. 

In light of the continued reliance on software supply chains as a critical component of business operations, the security of source code infrastructure has become more than an issue of development it has become a fundamental security priority that requires continuous monitoring, prompt remediation, and proactive defence.