Full Report
Security researcher Yuhang Wu at depthfirst has published a working proof-of-concept (PoC) exploit that executes commands as git on an unpatched self-managed GitLab 18.11.3 server. An ordinary authenticated user triggers it by committing two crafted Jupyter notebooks and requesting their diff. The chain needs no administrator rights, continuous integration (CI) runner access, victim interaction
Analysis Summary
# Vulnerability: GitLab Remote Code Execution via Oj JSON Parser Memory Corruption
## CVE Details
- **CVE ID**: Not yet assigned (The article notes that as of the publication date, CVE identifiers were not listed by GitLab or the researchers).
- **CVSS Score**: N/A (Estimated Critical based on unauthenticated/low-privileged RCE).
- **CWE**: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), CWE-121 (Stack-based Buffer Overflow).
## Affected Systems
- **Products**: GitLab Community Edition (CE) and Enterprise Edition (EE).
- **Versions**:
- 15.2.0 through 18.10.7
- 18.11.0 through 18.11.4
- 19.0.0 through 19.0.1
- **Configurations**: Self-managed instances. (The vulnerability involves the Oj Ruby gem versions 3.13.0 through 3.17.1).
## Vulnerability Description
The vulnerability is a chain of two memory corruption flaws in the `Oj` (Optimized JSON) Ruby gem used by GitLab to render Jupyter notebooks.
1. **Stack Overflow/Buffer Overwrite**: Oj uses a fixed 1,024-byte stack to track nesting depth. Deeply nested JSON arrays can exceed this stack, allowing an attacker to write `0x01` bytes into adjacent memory. This can be used to corrupt a callback pointer.
2. **Information Leak**: A flaw in how Oj handles large object keys allows an attacker to trigger an address leak. By truncating a length field, the parser returns a live pointer address in the rendered output, enabling the attacker to bypass Address Space Layout Randomization (ASLR).
When a user requests a diff of two crafted `.ipynb` files, GitLab’s Puma worker processes the malicious JSON, leading to arbitrary command execution as the `git` user.
## Exploitation
- **Status**: PoC Available (Published by depthfirst; build-specific for GitLab 18.11.3 on x86-64).
- **Complexity**: Medium (Requires narrowing the ASLR search, which can take 5 minutes to 2 hours).
- **Attack Vector**: Network (Authenticated user; requires no admin rights or victim interaction).
## Impact
- **Confidentiality**: High (Access to source code, Rails secrets, and credentials).
- **Integrity**: High (Ability to execute commands as the `git` user).
- **Availability**: High (Potential for service disruption via process manipulation).
## Remediation
### Patches
Self-managed operators should upgrade to the following versions or later:
- **GitLab**: 18.10.8, 18.11.5, or 19.0.2.
- **Oj Gem**: 3.17.3 (if managing Ruby environments independently).
### Workarounds
- No temporary workarounds are currently provided by the vendor or researchers. Upgrading is the only recommended mitigation.
## Detection
- **Indicators of Compromise**: Monitor Puma worker logs for unusual segmentation faults or crashes followed by unexpected outbound network connections (reverse shells) from the `git` user.
- **Detection Methods**: Use file integrity monitoring on the GitLab application directory and audit repository commits for highly nested or obfuscated Jupyter notebook (`.ipynb`) files.
## References
- [depthfirst Research: Achieving GitLab RCE via Two Ruby Memory Corruption Vulnerabilities] hxxps[://]depthfirst[.]com/research/going-depthfirst-achieving-gitlab-rce-via-two-ruby-memory-corruption-vulnerabilities
- [GitLab Release Notes] hxxps[://]docs[.]gitlab[.]com/releases
- [Oj Gem GitHub Repository] hxxps[://]github[.]com/ohler55/oj/pull/1014