GitLab RCE Exploit Chains Two Memory Safety Flaws in Oj JSON Parser
A sophisticated exploit chain leverages two previously undiscovered memory safety vulnerabilities in the Oj Ruby JSON parser to achieve remote code execution on default GitLab installations.
Researchers have uncovered a critical exploit chain targeting GitLab that can lead to remote code execution (RCE) on default installations. The attack hinges on the chaining of two memory safety flaws within the Oj Ruby JSON parser library, a component widely used across Ruby applications, including GitLab. These vulnerabilities, which had remained hidden for nearly five years, were discovered by Yuhang Wu of Depthfirst as part of the Open Defense Initiative.
The exploit targets GitLab's functionality for rendering Jupyter Notebook diffs. The ipynbdiff gem, used by GitLab for this purpose, parses notebook revisions using Oj's native parser. An authenticated user with push access can craft malicious JSON structures within notebook files and submit them as part of a commit diff. The first crafted notebook file abuses an unchecked nesting-stack write in Oj::Parser.usual.parse to redirect an internal buffer pointer. Subsequent heap operations then cause memory overlap, allowing attackers to gain control of a callback pointer.
This initial manipulation sets the stage for the second vulnerability: an unsafe 16-bit key-length narrowing in the Oj parser. This flaw leaks a fixed 29-byte memory slice. When combined with careful heap manipulation, this leak provides attackers with enough information to defeat ASLR (Address Space Layout Randomization) protections. By calculating the memory addresses of core libraries like libc and libruby, attackers can precisely control execution flow.
The exploit chain is particularly dangerous because it bypasses modern security measures, including GitLab's robust Server-Side Request Forgery (SSRF) defenses. Unlike previous RCE vulnerabilities that exploited SSRF against internal Redis instances, this attack targets a native, memory-unsafe dependency embedded within the otherwise memory-safe Ruby code. This makes it a more fundamental and harder-to-patch vulnerability.
Successful exploitation allows attackers to execute arbitrary code as the git system user, which powers GitLab's Puma workers. This level of access can expose sensitive data such as repository source code, Rails application secrets, service credentials, and any internal services accessible from the GitLab host. The potential impact includes data theft, code tampering, and lateral movement within an organization's network.
The vulnerability chain was made possible by pushing two specially crafted notebook files within a single commit-diff request. The first file corrupts the parser's state, and the second file, processed by the same vulnerable parser instance within a single request, triggers the corrupted callback to execute a shell command via system(). This sophisticated technique highlights the risks associated with native extensions in managed language environments.
GitLab has released patches for affected versions, including GitLab CE/EE 19.0.2, 18.11.5, and 18.10.8. GitLab.com instances were patched prior to disclosure, and dedicated customers required no action. However, operators of self-managed GitLab instances on affected versions must upgrade immediately. The Oj gem itself has been updated to version 3.17.3, addressing the core memory safety issues that had persisted since August 2021.
This incident underscores the pervasive risk of memory corruption vulnerabilities, even within seemingly secure applications. The discovery of multiple other CVEs within the Oj gem—including buffer overflows, use-after-free conditions, and integer overflows—emphasizes the need for rigorous security auditing of native code dependencies in all software stacks.