Please patch! Security update fixes critical vulnerability in GitLab

A number of vulnerabilities in GitLab make it possible to start CI pipelines as another user or to introduce cross-site scripting via commit notes.

Save to Pocket listen Print view
Red warning triangle floating in the room

(Image: JLStock/Shutterstock.com)

4 min. read
Contents

The operators of GitLab have published critical patch releases for the version control platform. The vulnerabilities fixed in versions 17.1.1, 17.0.3 and 16.11.5 affect both the Community Edition (CE) and the Enterprise Edition (EE). Anyone using the service on GitLab.com is already working with the updated version.

As usual with critical vulnerabilities, the release notes contain the urgent recommendation to install the latest version as soon as possible.

The critical vulnerability has the CVE (Common Vulnerabilities and Exposures) entry CVE-2024-5655 in the Mitre database. When writing this report, the links to the detailed descriptions of the vulnerability at Mitre and the National Vulnerability Database (NIST) did not work: they led to a 404 blank, or at HackerOne to the message that the report is not yet available.

The vulnerability is classified as Improper Access Control (CWE-284) and makes it possible to trigger a CI pipeline as another user. Even though GitLab classifies it as a critical risk with a CVSS score of 9.6 out of 10, there are probably no signs that attackers have already actively exploited it.

The cause of the vulnerability can be indirectly deduced from the breaking change associated with the patch: Apparently, access is gained via re-targeting in the merge process, which was previously able to automatically trigger a CI pipeline. For example, if the following two merge requests are pending at the same time:

  1. Merge x into main
  2. Merge y into x,

the first merge can take place first and then the second can flow directly via re-targeting into the main branch, which now contains the original target x.

With the patch release, GitLab no longer automatically triggers a CI pipeline when re-targeting merge requests, but users have to start it manually. The patch also disables GraphQL authentication via CI_JOB_TOKEN.

With a CVSS score of 8.7, GitLab classifies another vulnerability as high risk: CVE-2024-4901 allows cross-site scripting (XSS), more precisely stored XSS, i.e. code persistently located on the target server, to flow into a project when importing via commit notes.

Another high-risk vulnerability (CVSS value 8.1) is CVE-2024-4994 (detailed information is also missing here), which allows attackers to execute arbitrary GraphQL mutations via GitLab's GraphQL API using cross-site request forgery (CSRF).

Detailed descriptions of these and eleven other vulnerabilities can be found in the release notes for the patch releases at GitLab.

A quick update is recommended in any case, although apparently not everyone responsible for GitLab servers takes this advice seriously. In January, IT researchers published an investigation in which they found 5379 GitLab servers accessible on the Internet worldwide with a vulnerability for which a patch had already been available for two weeks at the time of the investigation.

The vulnerability from the year 2023 with the entry CVE-2023-7028 allowed attackers to send password reset emails to unverified email addresses and thus take over any accounts. Germany was ingloriously ranked second in the number of unpatched GitLab servers, with 730 systems behind the USA (964) and just ahead of Russia (721).

(rme)

Don't miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.