GitLab Remote Code Execution Vulnerability Exploited After Delayed Security Classification

Security researchers at depthfirst disclosed a critical remote code execution (RCE) vulnerability in GitLab on July 24, 2026, providing working exploit code for a flaw that the company had technically patched six weeks prior, on June 10, 2026. The exploit targets self-managed GitLab instances running version 18.11.3 that have not yet applied the necessary updates. This oversight, stemming from GitLab’s decision not to classify the fix as a security update, left numerous systems vulnerable to exploitation by authenticated users with project push privileges.

The vulnerability chain leverages two memory corruption bugs within the Oj gem, a Ruby JSON parser heavily reliant on native C code. These flaws were autonomously flagged by depthfirst’s automated systems and subsequently chained together by researchers to achieve RCE. The exploit’s mechanism involves an authenticated user committing a specially crafted Jupyter notebook to a project. When the commit’s difference (diff) is viewed, it leaks a heap pointer. By accumulating multiple such leaks, an attacker can precisely locate critical libraries in memory. Two further crafted notebooks are then used to execute arbitrary commands as the git user, which is the account under which the Puma web server operates within GitLab.

Crucially, this exploit requires no administrative privileges, no access to CI/CD runners, no user interaction with a victim, and no access to any projects other than the one the attacker has push access to. This accessibility makes it a significant threat to organizations using self-managed GitLab instances.

The Path to Exploitation: A Chronology of Events

The timeline leading to the public disclosure of this vulnerability highlights a critical gap in how security fixes are communicated and prioritized:

• May 21, 2026: depthfirst researchers report the two underlying Oj gem memory corruption bugs to the gem’s maintainer.
• May 27, 2026: Fixes for these Oj bugs are merged by the maintainer.
• June 4, 2026: Oj version 3.17.3, containing the fixes, is released.
• June 5, 2026: depthfirst researchers submit their findings regarding the GitLab RCE chain to GitLab.
• June 8, 2026: GitLab confirms the vulnerability internally.
• June 10, 2026: GitLab releases a patch update. However, this update (version 19.0.2 and related patches) lists the Oj gem update from 3.17.1 to 3.17.3 under general bug fixes, not within its dedicated security release notes.
• July 24, 2026: depthfirst publicly releases working exploit code for the GitLab RCE vulnerability.
• July 25, 2026: The news of the exploit and its implications begins to spread, prompting widespread concern.

This sequence reveals that while GitLab did implement a fix, its classification as a mere bug fix, rather than a security patch, meant that administrators triaging release notes would have had no immediate reason to prioritize it as an urgent security measure.

Technical Deep Dive: The Oj Gem and Memory Corruption

The core of this RCE vulnerability lies in two specific memory corruption flaws within the Oj gem. Oj, being a high-performance JSON parser implemented in C, is susceptible to low-level memory errors.

The first bug involves writing beyond a fixed 1,024-byte nesting stack. This overflow can allow an attacker to control the parser’s start callback function, a critical component in processing JSON data. By manipulating this callback, an attacker can divert the program’s execution flow.

The second bug exploits a flaw in how Oj handles object keys. It truncates a 65,565-byte object key to a mere 29 bytes within a signed 16-bit field. This truncation results in the return of a live heap pointer. GitLab’s notebook renderer, specifically the ipynbdiff gem, processes repository-controlled .ipynb JSON files through Oj::Parser.usual.parse within a long-lived Puma worker process. This means that attacker-controlled bytes can directly reach Oj’s C memory within the application.

When these two bugs are chained, the heap pointer leaked by the second bug can be used to locate essential libraries like libc in memory. The first bug, by controlling the start callback, can then be pointed to the system() function, a standard C library function that executes commands. This allows an attacker to execute arbitrary code on the server with the privileges of the git user.

Affected Versions and Mitigation Strategies

The vulnerability impacts a broad spectrum of GitLab Community Edition (CE) and Enterprise Edition (EE) users across all tiers, from Free to Ultimate. The affected versions are as follows:

• GitLab CE/EE: Versions 15.2.0 through 18.10.7
• GitLab CE/EE: Versions 18.11.0 through 18.11.4
• GitLab CE/EE: Versions 19.0.0 through 19.0.1
• Oj gem: Versions 3.13.0 through 3.17.1

The Oj gem version 3.17.2 did include other fixes identified during a broader review of the gem, but it did not address these specific memory corruption vulnerabilities.

GitLab has provided specific patched versions to address these issues:

• GitLab CE/EE:
  • 18.10.8 (for versions 15.2.0 to 18.10.7)
  • 18.11.5 (for versions 18.11.0 to 18.11.4)
  • 19.0.2 (for versions 19.0.0 to 19.0.1)

Users are strongly urged to upgrade to one of these patched versions immediately. Neither GitLab nor depthfirst has provided a public workaround for instances that cannot be upgraded.

A critical point of attention for users employing Helm charts or Kubernetes Operators is to verify the GitLab version within the webservice image that runs Puma, rather than solely relying on the chart or Operator version. This is because older versions of GitLab, specifically those from 15.2 through 18.9, are outside of GitLab’s standard security-maintained patch trains and will not receive backported fixes. For these instances, a migration to a supported release is the only viable solution.

The commands executed by the exploit run as the git user, the same user that the Puma web server operates under. The potential impact of such execution is significant, ranging from access to source code, sensitive Rails secrets, service credentials, and CI/CD data, to the ability to interact with internal services that the GitLab application can communicate with.

The public exploit code is specifically tailored for GitLab 18.11.3 on x86-64 architecture. It relies on specific gadget offsets, register states, and jemalloc behavior that were derived from that particular image. Furthermore, the recovered library base is only valid until the Puma master process restarts. This means that the exploit is not a simple drop-in solution for any arbitrary target and would require adaptation for different environments.

Analysis of GitLab’s Patching and Disclosure Practices

The decision by GitLab to not classify the Oj gem update as a security fix is a point of significant concern within the cybersecurity community. The absence of a CVE identifier, a CVSS score, and explicit mention of the notebook-diff exploit chain in their security advisories meant that the fix was likely overlooked by many security-conscious administrators. This practice, while perhaps intended to streamline patch notes, inadvertently created a window of opportunity for attackers.

The implications of this approach are far-reaching. It underscores the critical importance of clear and unambiguous communication from software vendors regarding security vulnerabilities. When a fix is buried within general bug fixes, it reduces the likelihood of timely patching, especially in large organizations with complex update processes. The principle of "defense in depth" relies on timely remediation of known threats, and misclassification of vulnerabilities directly undermines this.

depthfirst’s proactive disclosure, providing working exploit code, serves as a stark reminder of the adversarial landscape. While they state they are not aware of in-the-wild exploitation of this specific vulnerability, the public availability of the exploit code significantly lowers the barrier to entry for potential attackers.

The broader review of the Oj gem by depthfirst resulted in nine additional CVE advisories, indicating a general need for scrutiny of widely used libraries. However, the specific chain discovered for GitLab highlights the intricate ways vulnerabilities can be chained together across different software components to achieve critical impacts.

The exploit’s portability, while not a simple copy-paste operation, is a real concern. depthfirst reported that porting the exploit to different targets requires significant effort, estimating five to ten minutes for the memory search on a fresh installation and one to two hours on longer-running instances. This indicates that while complex, the exploit is within the realm of possibility for skilled attackers.

Industry Reactions and the Path Forward

As of the time of this report, GitLab has not yet provided a formal response to The Hacker News’s inquiries regarding why the fix was not initially classified as a security issue and whether a CVE will be assigned retrospectively. depthfirst has also been asked for further details on exploit portability.

The incident serves as a critical case study for both software vendors and users. For vendors like GitLab, it emphasizes the need for robust internal processes to identify, classify, and communicate security vulnerabilities with utmost clarity and urgency. For users, it highlights the necessity of diligently reviewing all patch notes, not just those explicitly marked as security releases, and implementing comprehensive vulnerability management programs.

The long-term impact of such vulnerabilities, especially when their remediation is delayed or obscured, can be severe. Organizations that remain unpatched are at significant risk of data breaches, system compromise, and operational disruption. The incident also calls into question the effectiveness of automated vulnerability scanning and management tools if they rely solely on vendor-provided security advisories that may be incomplete or misleading.

The cybersecurity community eagerly awaits further clarification from GitLab and continued insights from researchers like depthfirst. In the interim, the paramount recommendation for all self-managed GitLab users remains to upgrade to the latest patched versions to safeguard their infrastructure against this potent remote code execution threat. The incident underscores that even well-established software can harbor critical vulnerabilities, and vigilance, coupled with transparent security practices, is the most effective defense.