Critical GitLab RCE Vulnerability Exposed in Oj JSON Parser
Unmasking the Concealed Remote Code Execution Flaw
A critical remote code execution (RCE) flaw in self-hosted GitLab installations lay concealed for nearly six weeks. Although GitLab patched the underlying vulnerability on June 10, the company initially categorized the update merely as a routine dependency maintenance release. Recently, security research team depthfirst published a fully functional proof-of-concept exploit demonstrating how an unprivileged user can compromise a server by uploading a specially crafted Jupyter Notebook file. You can examine a functional demonstration on the GitLab RCE PoC repository on GitHub.
Executing this attack requires neither administrative rights, access to a GitLab Runner, nor social engineering interaction from another user. An adversary needs only standard write access to a single project. By committing a malicious .ipynb file and viewing the associated diff view, the exploit triggers automatically. The vulnerability afflicts self-managed GitLab instances running builds integrated with vulnerable versions of the Oj Ruby gem.
Anatomy of the Oj Memory Corruption Chain
Oj serves as a high-performance JSON parser for Ruby, heavily optimized with C extensions. Researchers discovered two distinct memory corruption defects within the library: an out-of-bounds buffer write and an information disclosure flaw that leaked memory addresses to bypass Address Space Layout Randomization (ASLR). Combined, these vulnerabilities grant an attacker arbitrary command execution under the privileges of the system-level git user.
GitLab utilized the Oj parser while rendering version diffs for Jupyter Notebook files. During diff generation, the server passed raw user-supplied file contents directly to the native C parser running within the primary Puma worker process. Structurally malformed JSON payloads corrupted heap memory, hijacking program control flow to execute arbitrary system commands.
Severe Impact on Enterprise Environments
Compromising the git service account carries consequences far beyond compromising an isolated repository. An attacker gaining this foot-hold can inspect proprietary source code, extract Rails secrets, access CI/CD pipelines, read authentication tokens, harvest cryptographic signing keys, and pivot to internal microservices reachable from the GitLab server. The ultimate blast radius depends heavily on the host configuration and assigned system privileges.
Affected Versions and Remediation Timeline
The flaw impacts both GitLab Community Edition (CE) and Enterprise Edition (EE) across all tiers. Vulnerable releases span versions 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, as well as 19.0.0 and 19.0.1. Official patches were introduced in releases 18.10.8, 18.11.5, and 19.0.2, which incorporate the remediated Oj version 3.17.3. Because GitLab.com was updated prior to public disclosure, action is required primarily for self-managed server administrators.
Controversy Surrounding Silent Patching Practices
Industry scrutiny has focused heavily on how GitLab communicated the security risk to system administrators. In the release notes published on June 10, upgrading Oj to version 3.17.3 was listed under routine bug fixes rather than critical security updates. GitLab omitted assigning a dedicated CVE identifier, provided no CVSS score, and failed to disclose that the update mitigated a high-severity RCE vector. Meanwhile, the same bulletin explicitly detailed other less critical vulnerabilities in a dedicated security table.
Administrators reviewing only the security advisory section remained unaware of the urgent need to patch the dependency. The public release of the functional exploit on July 24, six weeks after the patch drastically escalated the threat landscape for unpatched self-managed instances.
Researchers at depthfirst originally reported the memory corruption flaws to the Oj maintainer on May 21. Fixes were merged into the codebase on May 27, culminating in the release of Oj 3.17.3 on June 4. The research team submitted a complete exploit chain to GitLab on June 5; the vendor validated the issue three days later and released patched builds on June 10. While active exploitation in the wild was not initially documented, the public availability of the PoC renders immediate patching essential.
Administrators operating self-managed GitLab servers are strongly urged to update to the latest supported releases immediately, as no alternative workaround exists to mitigate the flaw short of updating the Oj library or GitLab instance.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
