Researcher Publishes Proof-of-Concept for GitLab RCE Vulnerability
A proof-of-concept exploit for GitLab allows authenticated users to execute arbitrary commands as the 'git' user on unpatched self-managed instances.
A security researcher has publicly released a proof-of-concept (PoC) exploit for a critical vulnerability in GitLab that allows authenticated users to execute arbitrary commands on self-managed instances. The exploit, published by Yuhang Wu at depthfirst, targets unpatched versions of GitLab Community Edition (CE) and Enterprise Edition (EE), specifically affecting versions 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1.
The vulnerability chain is triggered by a seemingly innocuous action: committing two specially crafted Jupyter notebooks and then requesting a diff between them. Crucially, this exploit does not require administrator privileges, access to a CI runner, interaction with other users, or any special access beyond standard user authentication within the GitLab instance. This low barrier to entry significantly increases the risk for affected deployments.
The technical mechanism behind the exploit involves two flaws within the Oj JSON parser for Ruby, a component used by GitLab. The first flaw allows an attacker to control a callback pointer within the parser, while the second leaks a heap address. This address leak is vital for bypassing Address Space Layout Randomization (ASLR), a security feature that makes it harder for attackers to predict memory locations. By combining these two vulnerabilities, an attacker can manipulate the parser's state to execute arbitrary code.
Successful exploitation allows commands to be run with the privileges of the 'git' user. The potential impact is substantial, as this user may have access to sensitive data such as source code, application secrets, credentials for CI/CD pipelines, and potentially internal services accessible from the GitLab application server. The exact reach depends on the specific isolation and configuration of the GitLab deployment.
GitLab has already released patches for these vulnerabilities. The first fixed versions are 18.10.8, 18.11.5, and 19.0.2. The underlying Oj library has also been updated, with version 3.17.3 being the first to contain the necessary fixes. GitLab.com instances were patched on June 10th, and dedicated customers do not require action. However, operators of self-managed GitLab instances are strongly urged to upgrade to a supported, patched version as soon as possible.
While the PoC is currently build-specific to GitLab 18.11.3 on x86-64, the underlying Oj vulnerabilities affect a broader range of GitLab releases. The researchers reported the Oj bugs on May 21st, with fixes merged by May 27th. The GitLab chain was reported on June 5th, and GitLab confirmed the issue on June 8th, releasing the patched versions on June 10th. As of July 24th, depthfirst was unaware of any in-the-wild exploitation attempts.
Neither GitLab's release notes nor the depthfirst disclosure initially provided specific CVE identifiers or CVSS scores for the chained vulnerabilities, although other Oj flaws found during the same review were assigned CVEs. This lack of immediate CVE assignment may have contributed to the vulnerability not being highlighted as a security fix in GitLab's release notes, instead being listed under general bug fixes. Users of Helm and Operator deployments should verify the GitLab version within the Webservice image, not solely the chart or Operator version.
This incident underscores the ongoing risks associated with complex software dependencies and the critical importance of timely patching for self-managed applications. The ability for an authenticated, low-privileged user to achieve remote code execution highlights a significant security gap that could be exploited by adversaries targeting vulnerable GitLab instances.