GitLab Patches Second Critical Pipeline Vulnerability In Last Month
GitLab has patched a second critical vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE) that could allow attackers to run pipelines as arbitrary users.
The vulnerability, tracked as CVE-2024-6385, was fixed in a critical patch release Wednesday and is similar to another flaw, CVE-2024-5655, that was patched on June 26. Both flaws were assigned a CVSS score of 9.6 by GitLab and enable the triggering of pipelines as another user “under certain circumstances.”
The GitLab continuous integration/continuous deployment (CI/CD) platform has more than 30 million registered users, and is used by major companies, including T-Mobile, Siemens and Nvidia, according to the GitLab website.
The critical vulnerabilities CVE-2024-6385 and CVE-2024-5655 could put developers’ projects at risk by enabling attackers to “run malicious code, access sensitive data and compromise software integrity,” Contrast Security CISO David Lindner told SC Media.
“This is REALLY bad, as it effectively turns off access controls for running pipelines, which is the lifeblood of moving software from development to production,” Lindner said in an email.
How to mitigate critical GitLab vulnerabilities
CVE-2024-6385 affects GitLab CE/EE versions 15.8 prior to 16.11.6, 17.0 prior to 17.0.4, and 17.1 prior to 17.1.2. The issue is resolved by updating to versions 16.11.6, 17.0.4 or 17.1.2, which GitLab recommends users do “as soon as possible.”
“Once a pipeline is compromised, software can be altered with malware, backdoors, or used to steal private information from organizations. This is difficult to detect because security scans are usually conducted earlier in the SDLC [systems development life cycle] process,” warned Ray Kelly, a security expert at Synopsys Software Integrity Group, in an email to SC Media.
Kelly added that while patching vulnerabilities immediately is important to prevent a major supply chain breach, there are additional measures developers can take to secure their pipelines.
“Introducing security scanning within the pipeline can help detect issues before they deployed,” Kelly noted.
With the vulnerability and patch management challenges, such as the two nearly identical, back-to-back GitLab CVEs, facing development teams, proactive measures to protect CI/CD environments are becoming more important to ward off a potential supply chain disaster, data breach or production-delaying denial of service incident.
Commenting on the earlier vulnerability CVE-2024-5655 in June, Skybox Security Vice President of Worldwide Systems Engineering Alistair Williams told SC Media the issue “highlights the need for organizations to move beyond reactive security measures.”
Williams recommended that organizations stay on top of threats by employing continuous monitoring of their development tools for security risks and identify compensating controls for scenarios where immediate patching of vulnerabilities is not feasible.
“This, combined with access to the latest threat intelligence, will help organizations identify weaknesses before they can be exploited. Furthermore, prioritizing vulnerabilities based on factors like exploitability, network accessibility, and potential financial impact allows organizations to focus on the most critical threats first,” Williams said.
While there is no evidence that either of the critical pipeline vulnerabilities have been exploited in the wild, GitLab accounts have been targeted by attackers exploiting a vulnerability tracked as CVE-2023-7028, which was disclosed and patched in January and added to the Cybersecurity & Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog in May.
This vulnerability could enable account takeover due to a flaw in the password reset process and was assigned the maximum CVSS score of 10 by GitLab. More than 2,100 GitLab instances were vulnerability to this flaw when it was added to the KEV, according to Shadowserver; Shadowserver’s online dashboard for CVE-2023-7028 indicates 1,890 instances remained exposed as of July 10.
READ MORE HERE
