Researcher Publishes GitLab RCE PoC Letting Authenticated Users Run Commands as Git

# GitLab RCE PoC Published: Any Authenticated User Can Execute Commands as Git via Jupyter Notebook Diff

## The Threat

A working proof-of-concept exploit for a remote code execution vulnerability in GitLab is now public. Security researcher Yuhang Wu of depthfirst has demonstrated that any authenticated user on an unpatched self-managed GitLab instance can execute arbitrary commands as the git operating system user — no administrator privileges, no CI runner access, no victim interaction required. The attack surface is a feature most security teams wouldn't think twice about: requesting a diff between two Jupyter notebook files.

The root cause lives two layers below GitLab itself. GitLab's notebook renderer passes repository-controlled .ipynb JSON directly to Oj::Parser.usual.parse inside a long-lived Puma worker process. Oj is a high-performance Ruby JSON parser with substantial native C code, and two bugs in its parser state handling create a chain: one corrupts a callback pointer via a fixed-size stack overflow, the other leaks a heap address that defeats ASLR. Together, they let the attacker reach system() through a build-specific gadget sequence. GitLab never sanitizes or isolates the Puma worker between parses, so both stages of the exploit ride inside the same process on a single diff request.

The public exploit targets GitLab 18.11.3 on x86-64 specifically, but the underlying Oj bugs span a much wider version range. depthfirst projects exploitation time of five to ten minutes against a two-worker installation, scaling to one to two hours against instances with more mature workers and wider ASLR search space. GitLab.com was patched on June 10. Self-managed installations that haven't upgraded are exposed right now, with a working exploit in the open.

## Severity and Impact

| Field | Detail |

|---|---|

| CVE | Not yet assigned (pending as of July 24, 2026) |

| CVSS Score | Not yet published |

| CVSS Vector | Not yet published |

| CWE | CWE-121 (Stack-Based Buffer Overflow), CWE-200 (Information Exposure) |

| Attack Vector | Network |

| Attack Complexity | High (ASLR brute-force required, build-specific gadget chain) |

| Authentication Required | Yes — any valid GitLab account |

| Privileges Required | None beyond authenticated access |

| User Interaction | None |

| Execution Context | As OS-level git user |

| Potential Reach | Source code, Rails secrets, service credentials, CI/CD pipeline data, internal services reachable from the application process |

*GitLab and depthfirst have not published CVE identifiers or CVSS scores for the two chain bugs. Nine additional CVEs covering separate Oj flaws from the same depthfirst review are listed separately.*

## Affected Products

GitLab Community Edition (CE) and Enterprise Edition (EE) — all tiers (Free, Premium, Ultimate):

Oj Ruby gem (root cause):

Not affected:

## Mitigations

Upgrade immediately. No temporary workaround exists. Both depthfirst and GitLab direct self-managed operators to upgrade to a fixed release:

Oj gem fix: Version 3.17.3 is the first release containing both upstream parser fixes.

Helm and Operator deployments require special attention: Check the GitLab version inside the Webservice container image — not the chart version or Operator version. These can diverge, and a current chart can still ship a vulnerable application image.

Additional hardening measures for environments that cannot immediately patch:

depthfirst was unaware of active exploitation as of July 24, but public PoC availability changes that calculus rapidly.

## References

---

## HackWire Analysis

The most important detail buried in this disclosure isn't the exploit technique — it's the absence of CVEs and CVSS scores six weeks after GitLab.com was patched. GitLab shipped the fix on June 10. The public PoC dropped July 24. That's 44 days during which self-managed operators had no formal severity signal to anchor a patching decision against. No CVE means the vulnerability doesn't surface in standard scanner feeds, SBOM tooling, or the dashboards most security teams actually use to triage. Organizations that run GitLab self-managed and rely on CVE-based alerting may have completely missed the window.

This is a pattern worth naming: vendors increasingly ship fixes before CVE assignment, ostensibly to reduce exposure time for customers, but the practical effect is that the loudest signal — a high CVSS score — never arrives until after a PoC is already public. The gap between patch availability and formal CVE publication is becoming an operational blind spot.

On the technical side, the exploit chain is instructive for defenders thinking about memory-unsafe parser libraries in interpreted language runtimes. GitLab is a Rails application, but the critical execution path runs through native C code in a third-party gem that GitLab's own security process doesn't own. The Puma worker reuse that enables both exploit stages in a single request is an architectural detail that almost no one auditing GitLab's Ruby surface area would have flagged. The lesson for teams running large Ruby applications: your attack surface includes every native extension in your Gemfile.lock, and process isolation between parser invocations is not a default you can assume.

For defenders right now: if you run GitLab self-managed, the patch decision is not optional. With a working PoC public and no authentication requirement beyond a valid account, the exploit becomes commodity within days.

— HackWire Editorial

## Related Coverage