GitLab RCE PoC Lets Authenticated Users Run Commands on Unpatched Servers

Security researcher depthfirst published working exploit code on July 24 for a GitLab remote code execution flaw that GitLab quietly patched on June 10 without filing it as a security fix. The vulnerability affects any self-managed GitLab CE/EE instance running versions 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, or 19.0.0 through 19.0.1 that has not applied the update. With no CVE assigned, no CVSS score, and the Oj 3.17.3 bump buried under "bug fixes" in the June 10 release notes rather than listed in the security-fix table, administrators triaging against GitLab's official advisory table had no signal that the patch was urgent, leaving a broad attack surface for installations that have not yet upgraded.

The exploit chain targets GitLab's in-tree ipynbdiff notebook renderer, which passes repository-controlled .ipynb JSON to Oj::Parser.usual.parse inside a long-lived Puma worker process. Two memory corruption bugs in the Oj Ruby JSON parser (versions 3.13.0 through 3.17.1) make the chain work: one writes past a fixed 1,024-byte nesting stack until the attacker hijacks the parser's start callback, while the other truncates a 65,565-byte object key to 29 in a signed 16-bit field and returns a live heap pointer that GitLab then renders into the commit diff. Repeating that leak lets an automated probe map libraries in memory, locate libc, and redirect the callback pointer to system() for arbitrary command execution as the git user running Puma.

Any authenticated user who can push to a project can run the attack, requiring no administrator rights, no CI runner access, no victim interaction, and no access to other projects. The attacker commits a crafted Jupyter notebook, opens its commit diff to harvest heap pointers, and follows up with two additional notebooks carrying the payload. The public exploit is calibrated for GitLab 18.11.3 on x86-64, with gadget offsets, register state, and jemalloc behavior derived from that specific image. depthfirst reports its autonomous system flagged both Oj bugs, which researchers then chained manually.

Administrators should upgrade immediately to GitLab 18.10.8, 18.11.5, or 19.0.2. Neither GitLab nor depthfirst offers a workaround, and versions 15.2 through 18.9 receive no backport because they fall outside GitLab's security-maintained patch trains, forcing those deployments to migrate to a supported release line. Operators using Helm charts or the GitLab Operator should verify the version inside the Webservice image running Puma rather than trusting the chart or Operator version. Because commands execute as git, attackers can reach source code, Rails secrets, service credentials, CI/CD data, and any internal service the application can reach, making a quick scan of exposed open ports and an SSL/TLS configuration review prudent first steps. Organizations running self-managed GitLab should also run a broader privacy checkup to confirm whether their instance is unintentionally reachable from the public internet.