“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,” Jonah Burgess, senior security researcher at Rapid7, said in a 28 May blog post.

“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.”

Similarly, a user with write access to a repository that has rebase enabled can engage in direct exploitation.

Regardless, the end result is a compromised server and read access to every repo on the instance. This could, in turn, lead to a credential dump, the compromise of additional systems, and the ability to modify any code hosted in the repository.

The exploit can be automated and run in seconds.

“The latest release versions at the time of research, Gogs 0.14.2 and 0.15.0+dev (commit b53d3162), were confirmed to be affected,” Burgess said.

“All prior versions supporting the ‘Rebase before merging’ style are likely vulnerable as well.”

In addition, the vulnerability impacts all supported platforms and installation methods. At the time of writing, a Shodan search revealed more than 1,100 vulnerable internet-facing instances of the service. Gogs is often left exposed in this manner to facilitate remote collaboration.

The vulnerability was discovered on 16 March and reported to Gogs maintainers a day later. The maintainers acknowledged the report on 28 March, but, according to Rapid7, have not responded to further contact attempts, despite being warned of the disclosure date of 28 May.