GitLab Remote Code Execution Vulnerability Exploited Six Weeks After Patch, Underscoring Importance of Security Classification

Security researchers at depthfirst have successfully developed and published working exploit code for a critical remote code execution (RCE) vulnerability in GitLab, a flaw that the software vendor had already patched six weeks prior. The exploit targets self-managed GitLab instances running version 18.11.3 that have not yet applied the update, allowing any authenticated user with the ability to push code to a project to execute arbitrary commands on the server as the git user. This discovery highlights a significant gap in GitLab’s security disclosure process, as the fix was not initially classified as a security update, potentially leading to delayed patching by administrators who might not have recognized its critical nature.

The vulnerability, which was publicly detailed on July 24, 2026, by depthfirst, leverages two memory corruption bugs within the Oj gem, a popular Ruby JSON parser. These bugs were autonomously flagged by depthfirst’s automated systems and subsequently chained together by researchers to achieve code execution. The exploit chain begins with an authenticated user committing a specially crafted Jupyter notebook to a project. When the commit’s diff is viewed, it leaks a heap pointer, providing attackers with a crucial piece of information to locate necessary libraries within the server’s memory. With this information, attackers can then deploy two additional notebooks that trigger the payload, leading to the execution of commands without requiring administrator privileges, CI/CD runner access, or direct interaction with a victim user.

The Technical Exploitation Chain

The technical intricacies of this RCE exploit are rooted in how GitLab handles Jupyter notebooks and the vulnerabilities within the Oj gem. GitLab’s notebook renderer, implemented as an in-tree gem called ipynbdiff, processes repository-controlled .ipynb JSON files. Crucially, this parsing occurs within a long-lived Puma worker using Oj::Parser.usual.parse. This mechanism allows attacker-controlled bytes to reach Oj’s manually managed C memory within the application process, creating the opportunity for exploitation.

The first of the two memory corruption vulnerabilities allows an attacker to write past a fixed 1,024-byte nesting stack. This overflow can ultimately lead to control over the parser’s start callback function. The second vulnerability is equally critical: it truncates a 65,565-byte object key to a mere 29 bytes within a signed 16-bit field. This truncation results in the parser returning a live heap pointer. GitLab’s rendering of this leaked pointer within the commit diff is what allows attackers to ascertain the memory location of the GNU C Library (libc). By combining the heap pointer leak with the ability to control the start callback, attackers can then redirect the execution flow to point to the system() function, enabling them to execute arbitrary commands.

The exploit code developed by depthfirst is specifically tailored for GitLab version 18.11.3 running on an x86-64 architecture. The researchers meticulously gathered gadget offsets, register states, and analyzed jemalloc behavior from this specific image. The success of the exploit relies on the recovered library base remaining stable until the Puma master process restarts. Consequently, the exploit is not a simple drop-in solution for all vulnerable GitLab instances; porting it to different environments requires significant effort.

A Question of Security Classification

A significant point of contention and concern arising from this incident is GitLab’s decision not to classify the fix as a security update. A review by The Hacker News revealed that the update for Oj to version 3.17.3, which contained the necessary patches, was listed under general bug fixes in GitLab’s June 10 patch release notes. It was notably absent from the security-fix table.

This omission meant that administrators and security teams triaging the release against their security matrices had no immediate indication that this update addressed a critical RCE vulnerability. The absence of a CVE identifier and a CVSS score further compounded the issue, removing standard indicators of severity that typically prompt urgent action. Consequently, organizations that meticulously followed GitLab’s security advisories might have overlooked this crucial update, leaving their self-managed instances exposed for an extended period.

GitLab’s maintenance policy typically ensures security patches are backported to supported versions. However, the Oj gem update for versions 15.2 through 18.9, which are outside the current security-maintained patch trains, did not receive a backport. This means that instances running these older, unsupported versions must upgrade to a currently supported release to receive the fix, a more involved process than applying a simple patch.

Timeline of Events

The discovery and patching of this vulnerability followed a relatively swift, albeit complex, timeline:

• May 21, 2026: depthfirst researchers report the two Oj memory corruption bugs to the gem’s maintainer.
• May 27, 2026: The maintainer of the Oj gem merges the fixes for these vulnerabilities.
• June 4, 2026: Oj version 3.17.3, containing the critical fixes, is released.
• June 5, 2026: depthfirst researchers submit their exploit chain targeting GitLab to GitLab.
• June 8, 2026: GitLab confirms the RCE vulnerability independently.
• June 10, 2026: GitLab releases a patch update that includes the Oj gem version 3.17.3. However, this update is not explicitly flagged as a security fix.
• July 24, 2026: depthfirst publicly releases their working exploit code for the vulnerability.
• July 25, 2026: The Hacker News publishes its report on the incident.

It is important to note that depthfirst has stated they are not aware of any instances of this vulnerability being exploited in the wild before their public disclosure.

Affected Versions and Mitigation Strategies

The vulnerability impacts all tiers of GitLab, including both Community Edition (CE) and Enterprise Edition (EE), from Free to Ultimate. The affected versions of GitLab CE/EE are:

• 15.2.0 to 18.10.7
• 18.11.0 to 18.11.4
• 19.0.0 to 19.0.1

The corresponding versions where these issues were fixed are:

• 18.10.8
• 18.11.5
• 19.0.2

The Oj gem itself was affected from versions 3.13.0 to 3.17.1, with fixes available in 3.17.3. Ruby itself is not directly vulnerable.

The primary mitigation strategy recommended by GitLab is to upgrade to one of the patched versions: 18.10.8, 18.11.5, or 19.0.2. For users running older, unsupported versions of GitLab (e.g., 15.2 through 18.9), a simple patch is not available. These users are compelled to migrate to a currently supported release to ensure their systems are protected.

A critical point for administrators managing GitLab deployments via Helm charts or Operators is to verify the version of the Webservice image that runs Puma, rather than solely relying on the chart or Operator version. This specific image contains the vulnerable code.

Broader Implications and Analysis

The implications of this incident extend beyond the immediate technical threat. The failure to classify the Oj gem update as a security fix raises questions about GitLab’s internal processes for vulnerability management and disclosure. In the cybersecurity landscape, clear and consistent classification of vulnerabilities is paramount for organizations to effectively prioritize patching efforts and allocate resources. When critical flaws are disguised as routine bug fixes, it creates a significant blind spot, potentially leaving systems vulnerable for longer than necessary.

The fact that an exploit was developed and publicly released six weeks after a fix was available underscores the need for proactive security practices. While depthfirst’s automated tools played a role in identifying the underlying Oj bugs, the manual chaining of these bugs into a functional RCE exploit demonstrates the ongoing ingenuity of security researchers and the potential for sophisticated attacks.

The commands executed via this exploit run with the privileges of the git user, which is the account associated with the Puma web server process. The actual impact of these commands is dependent on the isolation and configuration of the GitLab instance. However, at a minimum, attackers could gain access to sensitive data such as source code, Rails secrets, service credentials, CI/CD pipeline data, and potentially interact with internal services that the GitLab application can reach.

The depthfirst research team has indicated that porting the exploit to different environments requires considerable effort. They measured the memory search process taking between five to ten minutes on a fresh installation with two workers, and one to two hours on longer-running instances. This suggests that while the vulnerability is critical, the exploit’s immediate portability might be limited, offering a slight window for remediation.

GitLab has been approached for comment regarding the classification of the fix and the potential assignment of a CVE. As of the time of reporting, responses were pending. The Hacker News has also sought clarification from depthfirst regarding the exploit’s portability.

This incident serves as a stark reminder of the dynamic and often complex nature of cybersecurity. It emphasizes the critical importance of:

• Rigorous Vulnerability Classification: Vendors must have robust processes to accurately identify and classify security vulnerabilities, ensuring appropriate urgency is communicated to users.
• Proactive Patch Management: Organizations must have systems in place to track and apply security patches promptly, even those not explicitly flagged as critical if they address underlying issues that could be chained into exploits.
• Continuous Monitoring and Auditing: Regular audits of system configurations and versions, particularly for key components like web server images, are essential.
• Researcher-Vendor Collaboration: Open communication and clear disclosure processes between security researchers and vendors are vital for timely remediation and public safety.

As the cybersecurity landscape continues to evolve, with increasingly sophisticated threats and the growing reliance on complex software platforms like GitLab, diligence in security practices at both the vendor and user levels remains paramount.