Do Son 
TL;DR: Researchers at depthfirst released a working proof-of-concept for a GitLab RCE that runs commands as the git user. The chain abuses two memory corruption bugs in Oj, a native Ruby JSON parser used by GitLab. GitLab patched the flaw on June 10, 2026, yet shipped the fix without a CVE.
Why This GitLab RCE Matters
Any authenticated user who can push to a project can trigger the attack. No admin rights, CI access, or victim interaction are needed. Successful exploitation runs code as git, the account behind GitLab’s Puma workers.
Therefore, an attacker may reach repository data, Rails secrets, and internal services. That reach can lead to source-code theft, credential exposure, and lateral movement. A published exploit only sharpens the risk of this GitLab RCE.
How the Attack Works
GitLab renders readable diffs for Jupyter Notebook (.ipynb) files. An in-tree gem, ipynbdiff, passes repository bytes straight to Oj::Parser.usual.parse inside a long-lived Puma worker. As a result, attacker-controlled JSON reaches native C memory.
From Notebook Diff to Code Execution
The chain combines two flaws. First, an unchecked nesting stack lets deeply nested arrays write bytes past a fixed 1,024-byte buffer. Second, a narrowed 16-bit key length leaks a heap pointer through the rendered diff.
Alone, each bug is weak. One gives a repeated one-byte write. The other exposes a fixed 29-byte slice. Chained together, though, they hand an attacker a controlled callback pointer plus a way to defeat ASLR. The final step reaches a native call and runs a command.
Notably, the two Oj bugs sat in the parser for 1,753 days before the upstream fix. The vulnerable notebook path then shipped in GitLab for nearly four years. depthfirst laid out the full mechanism in its technical write-up.
Public Disclosure and Exploit Status
Both the vulnerability internals and the working chain are now open. depthfirst also published the proof-of-concept exploit code on GitHub. The team confirmed it runs against unpatched self-managed GitLab 18.11.3.
Still, depthfirst reports no in-the-wild exploitation so far, and GitLab reproduced the RCE independently. Meanwhile, GitLab did not label the fix as a security issue. Reporting by The Hacker News found the Oj 3.17.3 bump listed under bug fixes, not the security table. So many operators had little reason to rush the update.
Affected Versions
The notebook renderer ships in both Community Edition and Enterprise Edition. Subscription tier does not matter. A release is affected when it uses the Oj notebook path and bundles Oj 3.13.0 through 3.17.1.
- GitLab CE/EE 15.2.0 through 18.10.7 — fixed in 18.10.8
- GitLab CE/EE 18.11.0 through 18.11.4 — fixed in 18.11.5
- GitLab CE/EE 19.0.0 through 19.0.1 — fixed in 19.0.2
- Oj published gems 3.13.0 through 3.17.1 — fixed in 3.17.3
GitLab 15.1 and earlier used JSON.parse in this path, so they stay outside the chain.
Patch and Mitigation Steps
Self-managed operators should upgrade now to a supported fixed release. The June 10 patch moved maintained lines to Oj 3.17.3. For exact branch details, check GitLab’s patch release notes.
GitLab stated that GitLab.com was already patched, and Dedicated customers need no action. For Helm, Operator, and custom images, the GitLab version in the Puma Webservice image is authoritative. Because the fix carries no CVE, teams should track it by Oj version rather than a security label.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
