GitLab Oj Spill RCE Exploit Goes Public
The GitLab Oj Spill RCE is now public: a working exploit chain and full technical writeup were released on July 24 for a remote-code-execution flaw that GitLab quietly patched six weeks earlier, on June 10. If your self-managed GitLab instance is still on 18.10.7 or older, any developer who can push a commit can now run commands as the git user — no admin rights, no social engineering, just ordinary write access.
What Happened
The GitLab Oj Spill RCE chains two memory-corruption bugs discovered by AI-assisted code auditing firm depthfirst inside Oj, the native C JSON parser GitLab depends on through its bundled ipynbdiff gem, which renders diffs of Jupyter notebook files. The first bug is an out-of-bounds write: Oj’s parser tracks nesting depth in a fixed 1,024-byte buffer with no bounds check, so a deeply nested notebook can sweep past the buffer and overwrite an interior heap pointer. The second is a heap-pointer disclosure caused by a signed 16-bit key-length field that silently narrows an overlong JSON key, leaking a live heap address back through the rendered notebook diff.
Chained together, the leak locates libc and libruby in memory, defeating ASLR, and the write redirects Oj’s parser callback into system(). The result: any authenticated GitLab user who can commit a crafted .ipynb file — and view its diff on the commit page — triggers remote code execution as git inside a Puma worker. That level of access exposes source code, Rails secrets, CI/CD credentials, token-signing material, and any internal service reachable from the GitLab application server.
Affected: GitLab CE and EE versions 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1, across every tier (Free, Premium, Ultimate). Fixed in 18.10.8, 18.11.5 and 19.0.2, all of which bundle the corrected Oj 3.17.3. GitLab.com itself was patched by the June 10 release; only self-managed installations remain exposed. depthfirst says it is not aware of in-the-wild exploitation as of publication — this followed a coordinated private disclosure — but that changes the moment attackers work from the now-public proof-of-concept code.
Why It Matters
No CVE identifier was requested for either of the two chained bugs used in this exploit — only nine unrelated Oj bugs found in the same review received CVE numbers. Security teams that track patch compliance purely by CVE feed will not see this one flagged anywhere, which is exactly the “advisory is not the same as patched” pattern DIESEC has tracked across SharePoint, Veeam, PTC Windchill and Oracle PeopleSoft this year. Self-hosted GitLab is the default choice for many DACH Mittelstand and regulated-industry engineering teams who keep source control on-premises for data-residency reasons — and an RCE reachable by any of your own developers, not just an external attacker, is a materially different risk model than a typical perimeter CVE.
What You Should Do Now
- Check your GitLab version against the affected ranges above. If you are on 18.10.7 or earlier, 18.11.4 or earlier, or 19.0.1 or earlier, upgrade to 18.10.8, 18.11.5 or 19.0.2 today.
- If you manage the Oj gem directly outside a GitLab upgrade, confirm it is on 3.17.3 or later — this is the version that first contains both fixes.
- For Helm or Operator-based GitLab deployments, verify the actual GitLab version inside the Webservice/Puma image, not just the chart or Operator version number — these can silently drift out of sync.
- Until patched, consider restricting who can push Jupyter notebook files to repositories, or disabling notebook diff rendering, as a temporary compensating control.
If you cannot patch immediately, treat every developer commit account on the affected instance as a potential path to full application compromise until the upgrade is complete — this is not a theoretical risk reserved for external attackers.
DIESEC Perspective
This is the third time in 2026 that DIESEC has flagged a self-hosted developer platform — after Gogs/Gitea in May and again in July — where the patch existed for weeks before the risk became visible to security teams tracking CVE feeds rather than vendor release notes. Self-hosted tooling tends to have no clear internal owner for patch cadence the way a commercial SaaS product does; that gap is exactly where six-week-old fixes turn back into live incidents the moment a researcher publishes working exploit code.
Not sure whether your self-managed GitLab instance is still exposed to the Oj Spill RCE chain? Contact DIESEC for a rapid patch verification and developer-access exposure review.
Sources: depthfirst | The Hacker News
Published: 2026-07-28 | Category: Vulnerabilities & Patches | ~4 min read
