GitLab RCE PoC lands 6 weeks after a fix labeled a bug

Your patch process almost certainly keys off the vendor's security advisory table. That's the failure mode here. GitLab shipped a fix on June 10 that it classified as a bug, so it never appeared in the security release notes — and on July 24 a researcher published a working GitLab RCE exploit for the versions that fix covers. If you run self-hosted GitLab and you only patch when the advisory says "security," you've been sitting on this for six weeks.

What actually happened

Yuhang Wu at depthfirst published a proof-of-concept that executes commands as the git user on an unpatched self-managed GitLab 18.11.3 server, as reported by The Hacker News on July 25. The path in is unglamorous, which is what makes it bad: an ordinary authenticated user commits two crafted Jupyter notebooks and asks for the diff.

GitLab's notebook renderer — an in-tree gem called ipynbdiff — hands repository-controlled .ipynb JSON to Oj::Parser, and two memory-corruption bugs in Oj (a Ruby JSON parser written largely in native C) make the chain work. The first notebook leaks a heap pointer through the commit diff; repeat it and an automated probe locates the libraries in memory; the second corrupts the parser into running commands. No admin rights. No CI runner access. No access to anyone else's project. No victim interaction.

Affected ranges are CE and EE 15.2.0–18.10.7, 18.11.0–18.11.4, and 19.0.0–19.0.1. First fixed releases: 18.10.8, 18.11.5, 19.0.2, all from June 10. The Oj bugs themselves were reported May 21 and patched May 27. There is no CVE assigned, which is the other half of why this slipped past people — if your tooling watches CVE feeds, there was nothing to watch.

Why this matters for your business

Self-hosted GitLab is one of the highest-value boxes a small company owns. It holds every repo, every deploy key, every CI secret. Running commands as git there is functionally the same as owning your production pipeline. And the entry requirement — "can push to a project" — includes every contractor, every intern, and anyone who has ever compromised one developer's credentials.

The operational lesson is broader than GitLab. Vendor severity labels are a vendor's risk model, not yours. A parser bug that reads as a stability nit inside a large engineering org reads very differently when the affected box is the single system holding all of your source code. We've watched teams build careful patch discipline that is nonetheless load-bearing on someone else's triage decision, and this is what that costs.

Two concrete changes. First, for the handful of systems where compromise means game over — your Git host, your CI, your identity provider — track upstream releases, not just security advisories. Patch minor versions on a schedule regardless of label. Second, check who can actually push. Most self-hosted GitLab instances we look at have a dozen accounts with more access than anyone remembers granting.

If you're behind: update to 18.10.8, 18.11.5, or 19.0.2, then review your instance's audit events for unexpected .ipynb commits and diff requests.

Sources: The Hacker News, GitLab releases.