Security researchers at depthfirst have successfully demonstrated a critical remote code execution (RCE) vulnerability in GitLab, a flaw that the software vendor had patched six weeks prior to the public exploit’s release. The exploit, made public on July 24, 2026, targets self-managed GitLab instances running version 18.11.3 that have not yet applied the June 10 security update. This discovery raises significant concerns about the effectiveness of vulnerability disclosure and patching processes, particularly when security fixes are not clearly communicated as such.
The vulnerability allows any authenticated user with the ability to push code to a project to execute arbitrary commands with the privileges of the git user on the affected server. The attack chain is sophisticated, leveraging a subtle interplay between GitLab’s notebook rendering capabilities and underlying Ruby JSON parsing libraries. Crucially, the exploit does not require administrator privileges, access to CI/CD runners, or any form of victim interaction beyond the ability to push commits. This accessibility broadens the potential attack surface considerably, making it a potent threat to organizations that have not diligently updated their GitLab installations.
The Technical Underpinnings of the Exploit
At the heart of the RCE vulnerability lie two memory corruption bugs within the Oj gem (version 3.17.3 and earlier), a popular Ruby library used for parsing JSON data. Oj’s implementation, which relies heavily on native C code, proved susceptible to specific malformed inputs. GitLab’s ipynbdiff gem, responsible for rendering Jupyter notebooks (.ipynb files) and their commit differences, inadvertently passes repository-controlled JSON data to Oj’s parser within a long-lived Puma worker process. This allows attacker-controlled bytes to directly interact with Oj’s C-managed memory, creating the conditions for exploitation.
The first memory corruption bug allows an attacker to write past a fixed 1,024-byte nesting stack. This overflow can be manipulated to control the parser’s start callback function, a critical component in the JSON parsing process. The second bug involves the truncation of a large object key (65,565 bytes) to a mere 29 characters within a signed 16-bit field. This truncation results in the leakage of a live heap pointer.
The exploit chain meticulously crafts these vulnerabilities. By committing a specially designed Jupyter notebook, an attacker can trigger the heap pointer leak. Repeated execution of this process allows for the automated probing and identification of essential libraries within the server’s memory, such as the C standard library (libc). With these memory addresses located, two additional crafted notebooks are used to trigger the second vulnerability. This second payload directs the start callback, now under the attacker’s control, to execute the system() function, thereby enabling arbitrary command execution on the server.
A Discrepancy in Disclosure and Patching
A significant point of contention and concern surrounding this vulnerability is GitLab’s classification of the fix. The update that addressed these memory corruption bugs was released on June 10, 2026, as part of a patch release. However, GitLab did not formally categorize this fix as a security update. A review by The Hacker News revealed that the update to Oj version 3.17.3 was listed under general bug fixes in the release notes, not within the dedicated security advisories or tables.
This omission had critical implications for system administrators and security teams. Without a CVE identifier, a CVSS score, or explicit mention of a notebook-diff-related security issue, operators triaging the June 10 patch release would have had no specific reason to prioritize it as an urgent security measure. This oversight likely contributed to the six-week delay between the patch being available and the public demonstration of a working exploit, leaving numerous self-managed instances vulnerable.
Affected Versions and Scope
The vulnerability impacts all tiers of GitLab, including Community Edition (CE) and Enterprise Edition (EE), across Free and Ultimate plans. The specific affected versions range from GitLab CE/EE 15.2.0 through 18.10.7, and 18.11.0 through 18.11.4. Versions 19.0.0 through 19.0.1 are also vulnerable. The underlying Oj gem versions affected are 3.13.0 through 3.17.1. Notably, Ruby itself is not directly vulnerable; the issue lies within the Oj gem’s implementation.
The table below summarizes the affected and patched versions:
| Component | Affected Versions | First Fixed Version |
|---|---|---|
| GitLab CE/EE | 15.2.0 to 18.10.7 | 18.10.8 |
| GitLab CE/EE | 18.11.0 to 18.11.4 | 18.11.5 |
| GitLab CE/EE | 19.0.0 to 19.0.1 | 19.0.2 |
| Oj gem | 3.13.0 to 3.17.1 | 3.17.3 |
It is important to note that Oj version 3.17.2 contained other fixes derived from the same security review but did not address these specific memory corruption bugs. Therefore, upgrading to 3.17.3 or later is essential for mitigating the vulnerability.
Chronology of Discovery and Disclosure
The timeline of this vulnerability’s discovery, patching, and public exploit release highlights several critical junctures:
- May 21, 2026: depthfirst researchers report the two Oj memory corruption bugs to the Oj maintainer.
- May 27, 2026: The Oj maintainer merges fixes for the identified bugs.
- June 4, 2026: Oj version 3.17.3, containing the crucial fixes, is released.
- June 5, 2026: The GitLab security team receives a report detailing the exploit chain.
- June 8, 2026: GitLab confirms the RCE vulnerability internally.
- June 10, 2026: GitLab releases patch versions 18.10.8, 18.11.5, and 19.0.2, which include the fix for the Oj gem. Crucially, this release is not flagged as a security update.
- July 24, 2026: depthfirst publishes working exploit code for the vulnerability.
depthfirst has stated that they are not aware of any instances where this vulnerability has been exploited in the wild prior to their public disclosure. They also confirmed that GitLab independently reproduced the RCE, lending credibility to their findings. The broader security review conducted by depthfirst on the Oj gem resulted in nine additional CVE advisories, indicating a significant security posture issue within that component, though none of those other advisories are related to the notebook diff chain.
Broader Implications for GitLab Deployments
The successful exploitation of this vulnerability carries significant implications for organizations running self-managed GitLab instances. The commands are executed as the git user, which is the account under which the Puma web server typically runs. The extent of potential damage depends heavily on the isolation and privileges afforded to this user within the server’s environment.
In a less isolated setup, an attacker could gain access to sensitive data such as source code, Rails application secrets, service credentials, CI/CD pipeline data, and potentially interact with internal services that the GitLab application has network access to. This could lead to further compromise of the internal network and associated systems.
The public exploit code released by depthfirst is specifically tailored for GitLab version 18.11.3 running on x86-64 architecture. The exploit relies on precise gadget offsets, register states, and specific behaviors of the jemalloc memory allocator. These elements are derived from the specific GitLab image used for testing. Consequently, the exploit is not a "drop-in" solution that can be immediately applied to any arbitrary vulnerable target without significant adaptation. Porting the exploit to different architectures or GitLab versions would require considerable effort and reverse engineering.
depthfirst estimates that the memory search phase of the exploit takes approximately five to ten minutes on a freshly installed two-worker setup and up to two hours on longer-running instances. Their detailed write-up on the exploit chain provides a comprehensive technical deep-dive for those interested in the specifics.
Deployment Considerations and Patching Recommendations
A critical aspect for administrators to understand is how to correctly identify vulnerable instances. The exploit targets the version of the Webservice image running Puma, not necessarily the GitLab chart or Operator version. This means administrators must verify the specific version of the running application, not just the deployment tool’s version.
Furthermore, older versions of GitLab, specifically those from 15.2 through 18.9, do not receive backported fixes for this vulnerability. These versions fall outside GitLab’s standard security maintenance policy. For organizations running these older, unsupported versions, the only secure path forward is to upgrade to a currently supported release that includes the necessary security patches.
The recommended upgrade paths are:
- GitLab CE/EE 18.10.8
- GitLab CE/EE 18.11.5
- GitLab CE/EE 19.0.2
For those unable to immediately upgrade, depthfirst and GitLab do not currently offer any known workarounds to mitigate this specific vulnerability.
Official Responses and Pending Inquiries
As of the publication of this article, The Hacker News has reached out to both GitLab and depthfirst for further clarification. Inquiries have been sent to GitLab regarding the decision not to classify the June 10 patch as a security fix and whether a CVE identifier will be retroactively assigned. depthfirst has been asked about the portability of their exploit to different environments. Responses from both parties are pending.
The incident underscores the vital importance of clear and transparent communication regarding security vulnerabilities. When patches are not explicitly labeled as security fixes, the risk of them being overlooked or deprioritized increases significantly, leaving systems exposed to potentially devastating attacks. Organizations must maintain robust patch management processes and actively monitor security advisories, even for releases that are not immediately flagged as critical security updates, to ensure the integrity and security of their development pipelines and infrastructure.
