The GitLab RCE That Hid in a Bugfix: How a Silent Oj Patch Left Self-Managed Servers Exposed

A GitLab remote code execution chain sat in the wild for six weeks disguised as a routine dependency bump — and on July 24, security firm depthfirst published a working exploit that turns any authenticated pusher into a command executor running as git. The catch: GitLab didn’t classify the fix as a security patch, didn’t file a CVE, and buried the Oj 3.17.3 upgrade under “bug fixes” in the June 10 patch notes. Operators who triage releases by the security-fix table had zero signal to prioritize it. Now the exploit code is public on GitHub, and every self-managed instance still on GitLab 18.11.3 or an older vulnerable line is a soft target.

How a Ruby JSON Parser Became a Root-Level Weapon

According to depthfirst’s writeup, two memory corruption bugs in Oj — a Ruby JSON parser written largely in native C — form the backbone of the chain. GitLab’s in-tree ipynbdiff gem passes attacker-controlled .ipynb JSON straight into Oj::Parser.usual.parse inside a long-lived Puma worker, so untrusted bytes hit manually managed C memory inside the application process. One bug writes past a fixed 1,024-byte nesting stack until the attacker controls the parser’s start callback. The other truncates a 65,565-byte object key into a signed 16-bit field and returns a live heap pointer that GitLab helpfully renders back into the commit diff.

Why it matters: this is a textbook example of a supply-chain adjacent flaw where the vulnerable library got a clean, silent patch upstream, and the downstream consumer inherited the fix without labeling it. If your security posture depends on vendor severity tags, you missed this one. Picture a mid-sized fintech running a hardened self-managed GitLab instance — the security team scanned the June 10 release notes, saw no CVEs against their tier, and moved on. Six weeks later, any contractor with push rights on a single project can pop the box.

The editorial take: silent security fixes shipped as “bug fixes” are a governance failure, not a communications oversight. Vendors need to stop optimizing patch notes for optics and start optimizing them for defenders.

Why the Blast Radius Is Bigger Than “Just Git”

The exploit runs commands as the git user — the account behind Puma. On paper that sounds contained. In practice, depthfirst’s analysis notes that the reachable surface includes source code across every project on the instance, Rails secrets, service credentials, CI/CD data, and any internal service the application can reach on the network. All tiers are affected: CE and EE, Free through Ultimate. Ruby itself is not affected; the flaw lives entirely in Oj.

Why it matters: for organizations using GitLab as the source of truth for regulated code — think medical device firmware, healthcare software pipelines, or logistics platforms tracking chain-of-custody data — a git-level RCE is functionally a full-tenant compromise. Rails secrets alone give an attacker session forgery, and CI/CD credentials pivot into cloud accounts. If you’re running GitLab as the backbone of a supply chain traceability system, one authenticated contractor can rewrite build artifacts before they’re signed.

One prediction: within 60 days, at least one public incident report will trace back to this chain, most likely at an organization running GitLab on a line between 15.2 and 18.9 that received no backport at all.

The Kubernetes and Helm Trap Nobody’s Talking About

The patched versions are 18.10.8, 18.11.5, and 19.0.2, with Oj bumped to 3.17.3. But there’s a subtle operational trap for anyone running GitLab on Kubernetes: the version that matters is the GitLab version inside the Webservice image running Puma, not the Helm chart version or the Operator version. It’s entirely possible to be on a “current” chart while shipping a vulnerable Webservice image underneath.

Why it matters: platform teams often gate patching on chart versions in GitOps repos. If you’re one of them, your compliance dashboard is lying to you. A concrete scenario: your SRE team merges a Helm chart bump on July 25, the CI pipeline confirms the deploy succeeded, and your posture tooling turns green. Meanwhile the underlying Puma workers are still executing Oj 3.17.1 from an image that wasn’t rebuilt. depthfirst measured five to ten minutes for the memory search on a fresh two-worker install, and one to two hours on longer-running ones — plenty of window for an authenticated attacker who’s already inside.

The take: container-native deployments have a version-attestation problem. Image SBOMs need to be treated as first-class inventory, not build-time metadata.

Why the Public PoC Isn’t Plug-and-Play — Yet

The exploit depthfirst published targets GitLab 18.11.3 on x86-64 specifically. Gadget offsets, register state, and jemalloc behavior are all tuned to that image, and the recovered libc base only holds until the Puma master restarts. So the PoC is not drop-in against arbitrary targets — but the underlying Oj bugs are general, and porting the chain is described as “real work,” not research-grade novelty.

Why it matters: the window between “public PoC exists” and “weaponized scanner exists” is the defender’s runway. If you’re an operator, that runway is measured in days, not weeks. depthfirst reported the Oj bugs on May 21, upstream merged fixes on May 27, Oj 3.17.3 shipped June 4, GitLab was notified June 5, confirmed June 8, and patched June 10 — a tight disclosure timeline that only helps defenders who actually applied the update.

Prediction: expect a Metasploit module or a Nuclei template for the notebook-diff leak primitive within two weeks of this writing. The .ipynb upload path is trivially detectable and the pointer leak alone is a useful reconnaissance signal, even before full RCE portability lands.

FAQ

Q: Is my GitLab.com project affected? A: The published exploit and depthfirst’s analysis target self-managed GitLab installations. If you use GitLab’s hosted SaaS, GitLab operates the underlying infrastructure and applies patches centrally. The urgent action items apply to self-managed CE and EE deployments across all tiers.

Q: What versions do I need to be on to be safe? A: According to GitLab’s June 10 patch release notes, the fixed versions are 18.10.8, 18.11.5, and 19.0.2. The underlying Oj gem must be at 3.17.3 or later — note that 3.17.2 carried other fixes from depthfirst’s review but not these two specific memory corruption bugs.

Q: Is there a workaround if I can’t upgrade immediately? A: Neither GitLab nor depthfirst has published a workaround. Installs on the 15.2 through 18.9 lines receive no backport because those versions sit outside GitLab’s security-maintained patch trains, so those operators must move to a supported release. Restricting who can push to projects reduces the authenticated-attacker pool but does not eliminate the risk.

Key Takeaways

• Audit your patch triage workflow to flag dependency bumps that quietly ship upstream security fixes — vendor severity labels are no longer sufficient signal on their own.
• For Kubernetes-deployed GitLab, add explicit checks on the Webservice image’s GitLab and Oj versions, not just the Helm chart or Operator version.
• Treat any authenticated-push flaw as effectively unauthenticated in environments with permissive contractor or third-party access — the attacker model needs updating.
• Expect the exploit chain to be ported to additional GitLab versions within weeks; assume public scanners will follow shortly after.
• Container image inventories should be treated as first-class security data, not build-time metadata, because compliance dashboards keyed to chart versions will miss vulnerabilities like this one entirely.