GitLab Under Fire as Researcher Releases Working Exploit Code
Security researchers at depthfirst published working exploit code on July 24, 2026, for a serious GitLab vulnerability that had been quietly patched six weeks earlier on June 10. The exploit allows any authenticated user with push access to execute arbitrary commands as the git user on vulnerable self-hosted GitLab servers running version 18.11.3. The attack works by uploading specially crafted Jupyter notebook files that trigger memory corruption bugs when GitLab renders the commit diff. The exploit first leaks heap pointers to locate system libraries in memory, then uses additional notebooks to deliver the payload. Critically, the attack requires no administrative privileges, no CI runner access, and no victim interaction beyond the attacker having basic push rights to a single project.
The root cause lies in two memory corruption vulnerabilities in Oj, a Ruby JSON parser written in C that GitLab uses to process notebook files. One bug overflows a fixed buffer to hijack a parser callback function, while another truncates object keys and leaks live heap pointers that GitLab inadvertently displays in the diff view. These leaked addresses reveal the location of system libraries, and the buffer overflow redirects execution to the system function, giving the attacker command execution. The vulnerability affects all GitLab editions and tiers, from Community Edition to Ultimate, though Ruby itself is not vulnerable.
What makes this disclosure particularly concerning is that GitLab did not classify the June 10 fix as a security update. The Oj library version bump appeared in the bug fixes section of the release notes rather than the security section, no CVE identifier was assigned, and there was no public mention of the notebook exploit chain. Organizations that reviewed the release against GitLab's security advisories would have had no indication this was an urgent patch. depthfirst reported the Oj bugs on May 21 and the complete GitLab exploit chain on June 5, with fixes merged quickly, but the lack of security labeling meant many administrators likely delayed or skipped the update.
Administrators should immediately upgrade to GitLab versions 18.10.8, 18.11.5, or 19.0.2. Neither GitLab nor depthfirst have published workarounds for systems that cannot upgrade immediately, and no configuration change is known to fully disable the vulnerable code path. Commands executed through this exploit run with the privileges of the git account used by GitLab's application server, potentially exposing source code, Rails application secrets, service credentials, CI/CD variables, and any internal services the application can reach. While the public exploit specifically targets version 18.11.3 on x86-64 architecture, researchers note that adapting it to other GitLab versions on the same architecture typically requires only minor adjustments to memory offsets, making this a broad threat to unpatched installations. depthfirst reports no evidence of active exploitation in the wild, though they acknowledge having no visibility into production environments beyond their own research systems.
Stay secure — stay Wavasec. 🔐
