GitLab RCE Vulnerability Exploited via Oj JSON Parser Bugs Found by AI System

A pair of memory corruption vulnerabilities that lingered undetected in a widely used Ruby JSON library for nearly five years has been chained together to achieve remote code execution on default GitLab installations.

The flaws were surfaced not by a human researcher poring over source code, but by depthfirst, an autonomous vulnerability-discovery system operating under the Open Defense Initiative.

The finding underscores a growing trend in application security: AI-assisted systems are now finding deep, exploitable bugs in native code that traditional fuzzing and manual review missed for years.

GitLab RCE Vulnerability Exploited

The root cause sits in Oj, a high-performance JSON parser with a substantial C extension, used across the Ruby ecosystem for speed-critical parsing. GitLab reaches this vulnerable code through its in-tree ipynbdiff gem, which renders diffs for Jupyter .ipynb notebooks in commit views.

Any authenticated user with commit access can trigger the chain simply by pushing a specially crafted notebook and having someone (or an automated pipeline) view its diff. That’s a remarkably low bar for a vulnerability capable of full remote code execution.

The first flaw is an out-of-bounds write. Oj’s parser tracks nesting depth using a fixed 1,024-byte stack embedded in its parser struct, incrementing depth without any bounds check. A deeply nested JSON structure lets an attacker sweep single-byte selectors through adjacent memory, eventually corrupting an interior heap pointer.

The second is a heap-pointer disclosure. An overlong JSON key gets truncated through a signed 16-bit length field, causing the parser to read inline bytes that overlap a live external key pointer. GitLab then obligingly echoes that pointer back through the rendered diff leaking a heap address and defeating ASLR in the process.

Chained together, the leak locates libc and libruby in memory, while the write redirects the parser’s callback into system(), executing attacker-controlled commands as the git user. From there, an attacker can access source code, Rails secrets, CI/CD credentials, and token-signing material.

All GitLab tiers CE and EE, across Free, Premium, and Ultimate, are affected when the notebook transformer calls Oj::Parser.usual.parse and bundles a vulnerable Oj release:

GitLab 15.2.0–18.10.7 → fixed in 18.10.8
GitLab 18.11.0–18.11.4 → fixed in 18.11.5
GitLab 19.0.0–19.0.1 → fixed in 19.0.2
Oj gem 3.13.0–3.17.1 → fixed in 3.17.3

GitLab.com itself was patched as of the June 10 release. Ruby’s core interpreter is not implicated; the bugs live entirely in Oj’s native C extension.

Mitigation

Organizations running self-managed GitLab should upgrade immediately to 18.10.8, 18.11.5, or 19.0.2, all of which bundle the patched Oj 3.17.3. Teams managing Oj as a standalone dependency should upgrade directly to 3.17.3 or later.

For containerized deployments via Helm charts or the GitLab Operator, administrators should verify the actual GitLab application version baked into the Webservice image, since chart or Operator version numbers can be misleading indicators of patch status.

Beyond this exploit chain, depthfirst’s automated review of Oj produced nine additional CVEs (CVE-2026-54502 and CVE-2026-54896 through CVE-2026-54903), suggesting the parser’s native code harbored more latent risk than previously understood. Coordinated disclosure credited both the Oj maintainer and GitLab’s security team for responsive remediation.

For defenders, the incident is a pointed reminder that transitive dependencies, especially native C extensions buried several layers deep, deserve the same scrutiny as first-party code.