A newly disclosed security vulnerability in GitLab could allow attackers to execute remote code on affected self-managed GitLab servers. The exploit chain combines two memory safety flaws in the widely used Oj JSON parsing library, putting source code, application secrets, and internal services at risk.
The vulnerability was discovered by security researcher Yuhang Wu from Depthfirst as part of the Open Defense Initiative. During an automated security scan of the Oj library, the researcher identified 18 potential vulnerabilities. Seven of them were memory safety issues, including two critical flaws that had remained unnoticed for nearly five years.
According to the researcher, the two vulnerabilities were not severe on their own. One allowed repeated one-byte memory writes, while the other leaked a small portion of memory. However, when combined with carefully crafted memory manipulation techniques, the flaws could be used to bypass Address Space Layout Randomization (ASLR) and achieve remote code execution.
GitLab is affected because it uses the Oj parser while generating human-readable diffs for Jupyter Notebook (.ipynb) files. Before displaying a notebook diff, GitLab validates the JSON structure using the Oj library. Attackers could abuse this process by uploading specially crafted notebook files.
The exploit uses two malicious notebook files within a single commit. The first file corrupts the parser’s internal memory, while the second leaks memory addresses required to bypass security protections. Since GitLab’s Puma application server processes both files using the same parser instance, the attacker can eventually execute arbitrary commands on the server.
Unlike previous GitLab remote code execution vulnerabilities that relied on server-side request forgery (SSRF), this attack directly targets a native C extension used inside Ruby. This makes the exploit more difficult to detect and bypasses GitLab’s existing SSRF protections.
One of the most concerning aspects of the vulnerability is that it does not require administrator access. Any authenticated user with permission to push commits and view commit diffs could potentially trigger the exploit. No CI/CD access or user interaction is required.
If successfully exploited, attackers could execute commands as the “git” system user. This may expose repository source code, Rails secrets, service credentials, and other internal services running on the GitLab server. It could also lead to data theft, code modification, and further attacks within the organization’s network.
The vulnerability affects the following GitLab Community Edition (CE) and Enterprise Edition (EE) releases:
| Affected Version | Fixed Version |
|---|---|
| 15.2.0 to 18.10.7 | 18.10.8 |
| 18.11.0 to 18.11.4 | 18.11.5 |
| 19.0.0 to 19.0.1 | 19.0.2 |
The vulnerable Oj gem versions range from 3.13.0 to 3.17.1, while version 3.17.3 includes the required fixes.
GitLab.com had already received the security update before the public disclosure, and GitLab Dedicated customers do not need to take any action. However, administrators running self-managed GitLab instances are strongly advised to upgrade to the latest patched versions as soon as possible.
The vulnerable Oj code was introduced in August 2021, while GitLab started using the affected parser in July 2022 with the release of GitLab 15.2.0.
The researcher first reported the Oj vulnerabilities on May 21, 2026. Fixes for the library were released on June 4 with Oj 3.17.3. The GitLab-specific exploit chain was reported on June 5, confirmed on June 8, and patched on June 10 through GitLab versions 19.0.2, 18.11.5, and 18.10.8.
Besides the two flaws used in this exploit chain, the same research uncovered nine additional CVEs affecting the Oj library. These include heap and stack buffer overflows, use-after-free vulnerabilities, integer overflows, and other memory corruption issues, highlighting the risks of native C extensions used in otherwise memory-safe Ruby applications.
Security experts recommend that organizations using self-managed GitLab update immediately and review Ruby dependencies that include native C extensions to reduce the risk of similar attacks in the future.
Related Posts
