Critical GitLab Bug Threatens Software Development Pipelines

A critical GitLab vulnerability could allow an attacker to run a pipeline as another user.

GitLab is a popular Git repository, second only to GitHub, with millions of active users. This week, it released new versions of its Community (open source) and Enterprise Editions.

The updates include fixes for 14 different security issues, including cross site request forgery (CSRF), cross site scripting (XSS), denial of service (DoS), and more. One of the issues is deemed of low severity according to the Common Vulnerability Scoring System (CVSS), nine are of medium severity, and three are high — but there's also one critical bug with a CVSS score of 9.6 out of 10.

CVE-2024-5655 Offers Critical Threat to Code Development

That critical one, CVE-2024-5655, affects GitLab versions starting from 15.8 prior to 16.11.5, starting from 17.0 prior to 17.0.3, and starting from 17.1 prior to 17.1.1, according to the company. It enables an attacker to trigger a pipeline as another user, but only under circumstances which GitLab did not elaborate on (nor did it provide any other information about the vulnerability).

A pipeline automates the process of building, testing, and deploying code in GitLab. Theoretically, an attacker with the ability to run pipelines as other users can access their private repositories, and manipulate, steal, or exfiltrate sensitive code and data contained therein.

Unlike with CVE-2023-7028 — a 10 out of 10 account takeover bug known to have been exploited earlier this Spring — GitLab has thus far found no evidence of CVE-2024-5655 exploits in the wild. Though, that could quickly change.

A Compliance Issue, Not Just Security

 Issues rooted deep in the development process like CVE-2024-5655 can sometimes cause headaches beyond the simple risk they pose on paper.

"In a worst-case scenario, this vulnerability doesn't even have to be exploited to cost companies money in lost revenue," says Jamie Boote, associate principal consultant at Synopsys Software Integrity Group. The mere fact that a software or software-driven product was built using a vulnerable version of GitLab could itself be cause for concern.

"Pipeline vulnerabilities like this can not only pose a security risk but a regulatory and compliance risk as well. As US companies are working towards compliance with the Self-Attestation Form requirements that they need to meet to sell software and products to the US Government, not addressing this vulnerability could lead to a compliance gap which could put sales and contracts at risk," he explains. In particular, he points to line item 1c in Section III of the US Department of Commerce's Secure Software Development Attestation Form Instructions, which requires "Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk."

"Compliance with item 1c is in jeopardy for companies who don't address this vulnerability as an exploit would allow attackers to bypass those conditional access controls that companies are relying on for compliance," he concludes.