A newly discovered and so far unpatched critical vulnerability in the open source Gogs Git service not only demands immediate action from developers to secure their code, it also puts a spotlight on the potential issues in using self-hosted code platforms from small maintainers.

The hole is a critical argument injection vulnerability, discovered by a researcher at Rapid7, that allows any authenticated user to remotely execute code on a Gogs server by creating a pull request with a malicious branch name during a merge operation.

Rapid7 published an analysis of the vulnerability today, after the maintainer of Gogs did not respond to a request for status updates or to an offer to defer disclosure after it first reported the hole over two months ago.

“This is a serious vulnerability in software that isn’t commonly exposed to the public internet,”  Ryan Emmons, staff security researcher at Rapid7, said in an email.

“Gogs is typically used in an internal capacity; the most likely threat model is an attacker that has already gained access to an internal network environment exploiting the vulnerability to gain read/write access to source code repositories on the Gogs server. An attacker might leverage this access to silently tamper with source code and exfiltrate sensitive information, such as user password hashes and proprietary software.”

Rapid defensive action required

David Shipley, head of security awareness provider Beauceron Security, said both the Gogs maintainer and developers must take defensive action fast, because with the publication of a vulnerability “any attackers that didn’t know about this are going to be on it viciously.”

The fact that it has been left unpatched for months as of Thursday afternoon is another reason why CSOs and developers prefer GitHub, he added. With any open source project, there are worries about if or when a patch will be issued.

“The exploit requires no admin privileges and no interaction with other users,” Rapid7 said in its report. “An attacker operates entirely within their own account. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account and repository on any default-configured instance. Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user.”

In addition, any user with write access to a repository where rebase is already enabled can exploit it directly. On instances where repository creation is restricted, an attacker still only needs write access to any repository that has (or can have) rebase merging enabled.

If exploited, the vulnerability could not only lead to a Gogs server compromise, but from there it could turn into to a cross-tenant data breach, credential theft, lateral movement across an IT network, and software supply chain attacks through the code that is being developed on the compromised Gogs platform.

Until a patch is released, developers and CSOs in organizations with the platform in use should strictly enforce restricted network access to Gogs, Emmons said, and ensure that only those who need access can use the application. Furthermore, if user self-registration is not already disabled, it should be. Only administrators should be able to create new user accounts.

Rapid7 describes Gogs as a lightweight, self-hosted Git service written in Go that can run on any platform supported by the Go toolchain, including Linux, macOS, and Windows, as well as on ARM-based systems. It’s one of the more popular self-hosted alternatives to Microsoft-owned GitHub, says Rapid7, and is commonly deployed by companies, universities, and open-source projects.

Other self-hosted Git services for developers include GitLab Community Edition, Gitea, Forgejo (a fork of Gitea), and Atlassian’s Bitbucket Data Center.

Gogs pros and cons

In a blog earlier this month, Open Source Alternatives, which describes itself as a curated directory of self-hosted tools that replace paid software, noted that developers may chose to self-host a git server to avoid GitHub outages, arguing, “your repositories stay online when GitHub goes down, your GitHub Actions minutes bill disappears and your source code never leaves your own server”.

Emmons said Gogs is popular because it’s a lightweight and self-contained Git solution. It’s easy to deploy and run, he said, unlike many other Git servers that require heavy operational overhead and IT management. It’s also self-hosted on-prem software, which he said is ideal for teams that don’t, or cannot, for one reason or another, store source code in the cloud.

The main pro, Emmons said, is that Gogs is an appealing solution from an operational simplicity perspective. It works well for what it does, and it doesn’t take much management effort to keep it working. But, he added, “a major con is what we saw with this disclosure; Gogs is open-source software maintained by kind people in their free time, and the developers behind it don’t have the support of a major corporate information security team. That means security issues can sometimes present in ways that they typically wouldn’t for a well-funded enterprise product.”