GitLab RCE: Authenticated Users Achieve Root via Malicious Notebook – PoC Available

Vulnerability Overview

The flaw has no CVE identifier because the fix was listed only under a generic bug‑fix release (Oj gem upgraded to 3.17.3) on 2026‑06‑10. All GitLab CE/EE releases from 15.2.0 to 19.0.1 are affected, covering Free, Premium and Ultimate tiers.

Technical Analysis

GitLab’s ipynbdiff component renders Jupyter notebook (.ipynb) files as JSON diff views. It passes the notebook JSON directly to the Oj gem, a C‑based Ruby JSON parser that manually manages memory. Two memory‑corruption bugs in Oj are chained:

Bug 1 – Nested stack overflow with controllable callback: Oj maintains a fixed 1 KB nested stack. Exceeding the nesting limit overwrites the stack buffer, and a crafted payload can overwrite the parser’s start‑callback function pointer.

Bug 2 – Object‑key length truncation leaking a heap pointer: When parsing an overly long key (65 565 bytes), a signed 16‑bit field truncates the length to 29, returning an active heap pointer that is later rendered on the diff page, allowing the attacker to read the pointer value.

Complete Attack Chain

Step 1: Push malicious notebook → trigger heap‑pointer leak → read libc base address from diff page
↓
Step 2: Push additional notebooks → automated search locates a gadget in memory
↓
Step 3: Push final payload notebook → trigger nested stack overflow → hijack callback to system()
↓
Result: Execute arbitrary commands as the git user

Leak phase – repeated notebook pushes leak a heap pointer, enabling libc base discovery.

Control phase – the nested‑stack overflow overwrites the start‑callback with system().

Execution phase – the final notebook triggers the overwritten callback, running the attacker’s command.

Depthfirst measured the memory‑search stage to take 5–10 minutes on a freshly deployed two‑worker GitLab instance, and 1–2 hours on long‑running instances.

Why the Vulnerability Was Underestimated

The June 10 security update (versions 19.0.2, 18.11.5, 18.10.8) listed the Oj upgrade as a regular bug fix, omitting any CVE, CVSS score, or security advisory. Vulnerability‑management tools that rely on NVD/CVE data missed it, and many security teams assumed no urgent action was required. GitLab also announced that versions 15.2–18.9 would not receive dedicated patches because they are out of the official security maintenance window.

Proof‑of‑Concept Release

Depthfirst released a PoC targeting GitLab 18.11.3 on x86‑64, hosted at https://github.com/wupco/gitlab-rce-demo. The tool includes:

Optimizations for GitLab 18.11.3 x86‑64

Automated memory search to locate the libc base

Triggering of the Oj gem bugs via malicious .ipynb files

Attack duration of 5–10 minutes on new instances, up to 1–2 hours on long‑running ones

The PoC relies on a window before the Puma master process restarts to recover the libc base; porting to other architectures requires updating gadget offsets and register state.

Impact and Fixes

GitLab CE/EE 15.2.0 ~ 18.10.7 – first fixed in 18.10.8

GitLab CE/EE 18.11.0 ~ 18.11.4 – first fixed in 18.11.5

GitLab CE/EE 19.0.0 ~ 19.0.1 – first fixed in 19.0.2

Oj gem 3.13.0 ~ 3.17.1 – first fixed in 3.17.3

Users should upgrade to at least GitLab 18.10.8, 18.11.5, or 19.0.2. No configuration‑level mitigation exists; disabling the ipynbdiff rendering path is theoretically possible but practically difficult.

Detection and Mitigation

For Helm or Operator deployments, verify the actual GitLab version inside the Puma container, not the chart version. Monitor logs for the following indicators:

Sudden spikes of .ipynb file commits

Repeated requests to the commit‑diff streaming endpoint

Puma worker crashes or restarts accompanied by abnormal request patterns

Unexpected subprocesses, network connections, or internal‑service accesses originating from the git account

If immediate upgrade is impossible, contact GitLab for tailored guidance.

Conclusion

This vulnerability demonstrates that a seemingly low‑privilege authenticated user can achieve full system compromise when a security fix is mis‑classified and lacks proper CVE tracking. Effective defense requires deep vulnerability research beyond reliance on CVE databases.