GitLab RCE Explained — And How to Check If You're Affected

GitLab recently patched a remote code execution (RCE) vulnerability that never got a CVE, never got flagged as a security release — and was triggered by something as routine as pushing a Jupyter notebook and viewing its diff.

The root cause: two memory-safety bugs in Oj, a native C JSON parser GitLab uses to render notebook diffs. Both had sat undiscovered since 2021. Individually they looked minor — a one-byte write primitive, a small heap pointer leak. Chained together, they gave an attacker control over a parser callback pointer and a way to defeat ASLR, turning two "low severity" bugs into full RCE.

No admin access needed. No CI/CD access. No phishing or victim interaction. Just an authenticated user with ordinary push and diff-view permissions — access a contractor or new hire could have on day one.

Once exploited, code runs as GitLab's "git" system user, exposing source code, Rails secrets, CI/CD tokens, and any internal services reachable from the host.

GitLab.com and GitLab Dedicated were already protected before disclosure. Self-managed instances (Docker, Linux packages, Helm, Geo) needed to manually upgrade to 18.10.8, 18.11.5, or 19.0.2.

The bigger lesson for devs and SREs: "memory-safe language" guarantees don't extend to native C extensions buried in your dependency tree. Audit gems like Oj, Nokogiri, and similar native modules specifically — and don't rely only on official security advisories for patch prioritization, since not everything serious gets flagged as one.

Full exploit chain, affected versions, SOC detection steps, and remediation checklist here:
https://www.xpert4cyber.com/2026/07/gitlab-rce-vulnerability-explained.html