GitLab RCE Vulnerability Exploited Weeks After Patch Due to Undisclosed Security Fix

0 0 5 minutes read

Security researchers at depthfirst have successfully developed and published working exploit code for a critical vulnerability in GitLab, a popular platform for software development and collaboration. This exploit targets a flaw that GitLab had already patched six weeks prior, on June 10, 2026. The vulnerability, which allows any authenticated user with push access to a project to execute commands with the privileges of the git user on self-managed GitLab instances running version 18.11.3 that have not yet applied the update, highlights a concerning oversight in GitLab’s security patching process.

The exploit chain is particularly insidious because it leverages two memory corruption bugs within the Oj gem, a Ruby JSON parser heavily reliant on native C code. These bugs were autonomously flagged by depthfirst’s systems and subsequently chained together by researchers. The attack vector begins with an attacker committing a specially crafted Jupyter notebook to a project. By examining the commit diff of this notebook, an attacker can extract a heap pointer. Accumulating sufficient pointers allows for the automated probing and locating of essential libraries within the server’s memory. Following this, two additional notebooks are used to trigger the payload, enabling remote code execution (RCE). Crucially, this exploit bypasses the need for administrator privileges, access to CI/CD runners, victim interaction, or even access to other users’ projects.

A significant point of concern is that GitLab did not initially classify the fix for this vulnerability as a security update. An investigation by The Hacker News revealed that the update for Oj, specifically version 3.17.3, was listed under general bug fixes in the June 10 patch release notes, rather than in the dedicated security fix section. This omission meant that system administrators triaging the release against security bulletins would have had no reason to prioritize it as an urgent security patch, potentially leaving many systems vulnerable for an extended period. Consequently, there is no publicly assigned CVE identifier and no CVSS score associated with this specific exploit chain, further obscuring its severity from many security-conscious operators.

Table of Contents

The Technical Underpinnings of the Exploit

The effectiveness of this exploit hinges on two distinct memory corruption vulnerabilities within the Oj gem. The first bug allows an attacker to write beyond a fixed 1,024-byte nesting stack. This overwrite can ultimately gain control of the parser’s start callback function. The second vulnerability involves the truncation of a 65,565-byte object key to a mere 29 characters within a signed 16-bit field. This process, critically, returns a live heap pointer. GitLab’s notebook renderer, specifically a component called ipynbdiff integrated within the application, processes repository-controlled .ipynb JSON files. It passes this data to Oj::Parser.usual.parse within a long-lived Puma worker. This mechanism allows attacker-controlled bytes to directly interact with Oj’s manually managed C memory within the application process.

Researcher Publishes GitLab RCE PoC Letting Authenticated Users Run Commands as Git

The leaked heap pointer, once obtained, is utilized to locate critical libraries such as libc in memory. The control gained over the start callback, through the stack overflow, is then manipulated to point to the system() function, a standard C library function that executes commands. This combination effectively transforms the vulnerability into a remote code execution channel, allowing arbitrary commands to be run on the vulnerable server.

A Deeper Dive into Affected Versions and the Chronology of Discovery

The vulnerability impacts a broad spectrum of GitLab installations. Across all tiers, including GitLab Community Edition (CE) and Enterprise Edition (EE), from free to ultimate licenses, versions 15.2.0 through 18.10.7 are affected, with a fix available in 18.10.8. Further versions 18.11.0 through 18.11.4 are also vulnerable, patched in 18.11.5. For the latest release branches, versions 19.0.0 through 19.0.1 are impacted, with a fix in 19.0.2. The underlying Oj gem itself was vulnerable in versions 3.13.0 to 3.17.1, with the fix provided in 3.17.3. It is important to note that Ruby itself is not directly affected by these vulnerabilities. While Oj version 3.17.2 did contain other fixes stemming from the same security review, it did not address these specific memory corruption bugs.

The timeline of discovery and patching reveals a potentially critical gap between the identification of underlying issues and their secure remediation:

May 21, 2026: depthfirst reports the two critical Oj memory corruption bugs to the Oj maintainer.
May 27, 2026: The Oj maintainer merges the necessary fixes.
June 4, 2026: Oj version 3.17.3, containing the critical fixes, is released.
June 5, 2026: depthfirst submits their findings on the GitLab exploit chain to GitLab.
June 8, 2026: GitLab confirms the RCE exploit independently.
June 10, 2026: GitLab releases patch release 19.0.2, which includes the fix for the Oj gem but is not explicitly flagged as a security update.
July 24, 2026: depthfirst publishes their working exploit code, making the vulnerability widely accessible.

This timeline highlights that while the core components were fixed relatively quickly, the lack of immediate public disclosure as a security issue allowed for a significant window of opportunity for exploitation.

The Implications of Undisclosed Security Fixes

The decision by GitLab to categorize the fix for this critical RCE vulnerability under general bug fixes has significant implications for the cybersecurity posture of organizations relying on their platform. Without a CVE designation or explicit mention in security advisories, system administrators who diligently review patch notes for security-related updates may have overlooked this critical fix. This is particularly problematic for organizations that adhere to strict security protocols, where updates are often prioritized based on their security classification.

The commands executed through this exploit run with the privileges of the git user, which is the account under which Puma, GitLab’s web server, operates. The extent of potential damage depends heavily on the isolation and configuration of the GitLab instance. However, in a typical setup, an attacker could gain access to sensitive information including source code, Rails application secrets, service credentials, detailed CI/CD pipeline data, and potentially interact with other internal services accessible from the GitLab server.

The public exploit code is specifically engineered for GitLab version 18.11.3 running on x86-64 architecture. This means that while the underlying Oj bugs are general, adapting the exploit to different environments, such as varying architectures or GitLab versions outside the immediate scope, would require substantial effort. Factors like gadget offsets, register states, and jemalloc behavior are specific to the target image, and the leak of the library base is only stable until the Puma master process restarts.

Broader Impact and Recommendations for Mitigation

The vulnerability underscores the interconnectedness of the software supply chain. A vulnerability in a third-party library like Oj, when integrated into a widely used platform like GitLab, can have far-reaching consequences. depthfirst’s research into the Oj gem has reportedly yielded nine additional CVE advisories, indicating a broader set of potential security weaknesses within the library that may require further attention from its users.

For organizations utilizing GitLab, the primary recommendation is to upgrade immediately to one of the patched versions: 18.10.8, 18.11.5, or 19.0.2. There is currently no known workaround for users who cannot upgrade.

A crucial point of attention for administrators managing GitLab deployments, particularly those using Helm charts or Kubernetes Operators, is to verify the GitLab version within the Webservice image running Puma, rather than solely relying on the chart or Operator version. This is because older versions of GitLab (e.g., 15.2 through 18.9) that fall outside GitLab’s officially supported security maintenance patch trains will not receive backported fixes. For these instances, a migration to a currently supported release is the only secure path forward.

depthfirst has indicated that they are not aware of any instances of this vulnerability being exploited in the wild prior to their public disclosure. However, the availability of a working exploit significantly increases the risk of targeted attacks. The company is awaiting responses from GitLab regarding the classification of the fix and the potential assignment of a CVE, as well as from depthfirst regarding the portability of their exploit.

The incident serves as a stark reminder of the importance of transparency in security vulnerability disclosure and the critical need for organizations to maintain up-to-date software inventories and diligently apply all patches, regardless of their initial classification. A proactive approach to security, including continuous monitoring and rapid patching, is essential to defend against the ever-evolving threat landscape.