Listen to this Post
Introduction, A Small Bug Fix That Hid a Major Security Threat
Security vulnerabilities are not always announced with dramatic warnings or urgent security advisories. Sometimes they appear quietly inside ordinary software updates, disguised as routine bug fixes. That is exactly what happened with one of the most dangerous GitLab vulnerabilities discovered in recent years.
Researchers from Depthfirst recently demonstrated a fully working remote code execution (RCE) exploit against GitLab by chaining together two memory corruption vulnerabilities inside Oj, a high-performance Ruby JSON parser written in native C. Although GitLab fixed the underlying issues on June 10, 2026, the update categorized them as regular bug fixes rather than security vulnerabilities. As a result, many administrators likely delayed patching, unknowingly leaving production servers exposed.
The research reveals how a seemingly harmless component buried deep within GitLab’s software stack can become the starting point for complete server compromise. Even more concerning, the attack requires no administrator privileges, no CI/CD access, and no user interaction. Any authenticated developer capable of pushing code and viewing commit differences could potentially execute arbitrary commands on vulnerable GitLab servers.
The Discovery That Changed Everything
Depthfirst researchers published their proof-of-concept exploit on July 24, demonstrating that two independent memory corruption flaws inside the Oj JSON parser could be chained into complete remote code execution.
Instead of targeting
This approach uncovered an attack surface that had remained unnoticed for years.
Affected GitLab Versions
The vulnerability affects a wide range of GitLab Community Edition (CE) and Enterprise Edition (EE) releases.
Affected versions include:
GitLab 15.2.0 through 18.10.7
GitLab 18.11.0 through 18.11.4
GitLab 19.0.0 through 19.0.1
Administrators should immediately upgrade to:
GitLab 18.10.8
GitLab 18.11.5
GitLab 19.0.2
Versions prior to GitLab 15.2 are not affected because they relied on a different JSON parser for notebook processing.
Unfortunately, installations running unsupported GitLab branches between versions 15.2 and 18.9 will receive no security backports and require complete upgrades.
How the Attack Begins
The attack abuses
Whenever developers compare two commits containing Jupyter Notebook (.ipynb) files, GitLab converts the notebook into a human-readable format using a small internal library called ipynbdiff.
During this process, GitLab feeds notebook data directly into:
Oj::Parser.usual.parse
This parsing occurs inside the Puma application server, where native C code processes attacker-controlled JSON content.
That parser invocation becomes the gateway into memory corruption.
The First Vulnerability, Corrupting Internal Memory
The first vulnerability involves an unchecked nesting stack overflow.
Oj tracks JSON nesting depth using a fixed 1,024-byte internal array.
An attacker simply creates JSON containing more than 1,024 nested arrays.
Instead of stopping safely, the parser continues writing beyond the allocated buffer.
Although each overwritten byte always has the same value, the attacker controls how far the overwrite extends.
Eventually, critical parser structures become corrupted.
One overwritten field shifts an important internal pointer backward into memory that the parser does not own.
Once this corrupted pointer becomes cached during memory reallocation, subsequent Ruby allocations overwrite internal callback pointers that eventually control program execution.
The Second Vulnerability, Leaking Heap Addresses
Memory corruption alone rarely produces reliable code execution because modern operating systems use Address Space Layout Randomization (ASLR).
The second vulnerability solves this problem.
When GitLab processes an oversized JSON object key exceeding 65,565 bytes, a type conversion bug truncates its length into a signed 16-bit integer.
Instead of returning expected data, Oj accidentally leaks internal heap pointers directly into GitLab’s notebook diff output.
This information disclosure gives attackers valuable memory addresses required to bypass ASLR.
Without this leak, reliable exploitation would be significantly harder.
Turning Two Bugs Into Remote Code Execution
With memory corruption and address disclosure combined, attackers gain everything needed to execute arbitrary commands.
The exploit proceeds in multiple carefully coordinated stages.
The first notebook manipulates parser callback pointers while intentionally triggering an exception that delays execution.
GitLab continues processing additional notebook differences within the same Puma worker.
A second malicious notebook then activates the corrupted callback.
Instead of executing legitimate parser code, control jumps through carefully selected Ruby library gadgets before finally reaching:
system()
At this point, the
Why Shared Parser Objects Make It Worse
One particularly dangerous design choice amplifies the attack.
Oj::Parser.usual returns a singleton parser object shared across multiple threads inside the same Puma worker.
Once the parser becomes corrupted, every subsequent parsing operation performed by that worker relies on compromised internal state.
This dramatically increases exploit reliability while reducing the need for repeated attacks.
Potential Impact on Organizations
Successful exploitation grants command execution under the git account running GitLab’s Puma workers.
Depending on deployment architecture, attackers may gain access to:
Source code repositories
Rails secrets
API credentials
Service authentication tokens
Internal databases
Private infrastructure
Deployment pipelines
Repository modification capabilities
Lateral movement opportunities
Even organizations with strong network segmentation could face serious risks if GitLab has access to internal services.
Why Many Organizations May Still Be Vulnerable
Perhaps the most concerning aspect of this incident is not the exploit itself.
GitLab corrected the bugs more than a month before public disclosure.
However, because the fixes appeared under ordinary bug fixes instead of the official security advisory section, many administrators likely skipped immediate upgrades.
Most enterprise patch management systems prioritize security bulletins over routine maintenance releases.
This classification mistake may have unintentionally extended the vulnerability window across thousands of deployments.
Deep Analysis
The exploit demonstrates several advanced exploitation techniques commonly seen in modern memory corruption research.
Vulnerable Parsing Entry Point
Oj::Parser.usual.parse(json_data)
Example Deeply Nested JSON Structure
[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]
Repeating nesting beyond 1,024 levels triggers the parser overflow.
Example Oversized JSON Key
{
"AAAAAAAAAAAA...65565 bytes...AAAA":"value"
}
This triggers the integer truncation responsible for leaking heap addresses.
Checking the Installed GitLab Version
gitlab-rake gitlab:env:info
Docker Deployment Version
docker exec gitlab gitlab-rake gitlab:env:info
Kubernetes Deployment
kubectl get pods -n gitlab
kubectl describe deployment gitlab-webservice
Helm Users
helm list
Remember that the vulnerable component depends on the GitLab version inside the Webservice image rather than the Helm chart version.
Upgrade Package Installation
Ubuntu:
sudo apt update sudo apt install gitlab-ee
RHEL:
sudo yum update gitlab-ee
Verify Running Puma Workers
ps aux | grep puma
Review GitLab Logs
sudo gitlab-ctl tail puma
Unexpected notebook parsing errors or repeated crashes may indicate attempted exploitation.
Security Monitoring
Organizations should monitor:
Unexpected .ipynb uploads
Unusual notebook diff requests
Puma worker crashes
Sudden repository modifications
Outbound network connections initiated by GitLab
These indicators may provide early warning before full compromise occurs.
What Undercode Say
The most important lesson from this disclosure is not simply that GitLab contained an exploitable vulnerability. It is that software supply chains remain only as secure as their least visible dependency.
Oj is not a front-facing service. Most GitLab administrators have probably never heard of it. Yet a vulnerability buried inside this parser became capable of compromising entire development environments.
This research also highlights the growing importance of memory-safe programming languages. Native C libraries continue to offer exceptional performance, but they also introduce decades-old classes of vulnerabilities such as buffer overflows, integer truncation, pointer corruption, and use-after-free conditions. Many software vendors are increasingly exploring Rust and other memory-safe alternatives precisely because of incidents like this.
Another significant issue is vulnerability disclosure strategy. When a patch correcting a critical security issue is categorized merely as a “bug fix,” organizations naturally assign it a lower priority. In highly regulated environments, patch cycles are often driven by vendor security advisories. Missing that classification can leave thousands of systems exposed even after a fix exists.
The exploit chain itself demonstrates remarkable engineering. Neither vulnerability alone provided remote code execution. One corrupted memory while the other disclosed heap addresses. Only when carefully combined did they defeat modern operating system protections such as ASLR.
Development platforms like GitLab represent high-value targets because they centralize intellectual property, credentials, infrastructure automation, deployment pipelines, and production secrets. A compromise of the source code management platform often becomes a compromise of the entire enterprise.
Security teams should also reconsider how they evaluate “authenticated” attacks. Modern collaborative platforms frequently grant commit access to contractors, temporary developers, external contributors, or compromised accounts. Assuming authenticated users are inherently trusted is increasingly dangerous.
Finally, this incident reinforces an important operational principle. Every software update deserves review, even those labeled as ordinary maintenance releases. Hidden security fixes appear more often than many organizations realize, and attackers actively search release notes for clues that vendors may unintentionally reveal.
Organizations should strengthen monitoring around developer tooling, perform routine dependency audits, shorten patch deployment windows, and continuously validate third-party libraries that operate beneath business-critical applications.
Prediction
(+1) Security Transparency Will Improve After This Incident 📈
This disclosure is likely to encourage software vendors to classify security-related fixes more accurately, even when vulnerabilities originate in third-party dependencies. More organizations will prioritize rapid updates for development infrastructure, while future GitLab releases are expected to receive increased scrutiny around dependency security, parser isolation, and memory-safe components. The long-term outcome should be stronger supply-chain resilience and faster enterprise patch adoption.
✅ Confirmed: Depthfirst publicly released a working exploit demonstrating remote code execution by chaining two memory corruption vulnerabilities in the Oj parser used by GitLab.
✅ Confirmed: The attack can be performed by an authenticated user with permission to push code and view commit diffs, without requiring administrator privileges, CI/CD access, or victim interaction.
✅ Confirmed: GitLab has released patched versions (18.10.8, 18.11.5, and 19.0.2), and there is currently no validated configuration-only workaround, making upgrading the recommended mitigation.
▶️ Related Video (74% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: securityaffairs.com
Extra Source Hub (Possible Sources for article):
https://www.linkedin.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
