In short: On 24 July 2026, researchers at depthfirst released a working exploit for a critical remote code execution (RCE) flaw in self-hosted GitLab. GitLab had quietly patched it on 10 June — shipped as a "routine" maintenance update, with no CVE, no security advisory and no warning to administrators. Any authenticated user with push access can run commands on the server as the git account and reach source code, secrets and CI/CD data. If you run your own GitLab, upgrade now.
What happened
On 24 July 2026 the research team depthfirst published a full proof-of-concept exploit for a remote code execution chain in GitLab Community and Enterprise editions. The uncomfortable detail: GitLab had already fixed the underlying bugs six weeks earlier, on 10 June, but disclosed nothing. The change appeared under ordinary "bug fixes" in the release notes — no CVE identifier, no security advisory, no urgency communicated to the enormous population of self-managed GitLab administrators. As a result many teams never patched, because they were never told there was anything to patch.
A public exploit changes the risk overnight. It lowers the barrier so far that mass scanning and automated attacks against exposed, unpatched instances typically follow within days. This is the same pattern we described with the public exploit for vBulletin forums: the fix exists, but every un-updated server stays wide open — and here the servers in question hold companies' most sensitive asset, their code.
Why the flaw is so severe
The root cause is a pair of memory-corruption bugs in Oj, a widely used Ruby JSON parser written as a native C extension (affected Oj versions 3.13.0 to 3.17.1, fixed in 3.17.3). GitLab reaches that vulnerable code through an unexpected path: its notebook diff renderer, a small in-tree component called ipynbdiff, which converts Jupyter .ipynb files into human-readable diffs. When a user opens a commit diff for a notebook file, GitLab hands the raw repository bytes straight to the Oj parser inside its Puma worker process — and a crafted notebook triggers the corruption and, ultimately, code execution.
The prerequisites are alarmingly low. An attacker needs only an authenticated account with push access to any project — no administrator rights, no CI access and no interaction from a victim. They commit a specially crafted notebook, view its diff, and the exploit runs commands as the git user. The bugs were introduced back on 8 August 2021 and the vulnerable notebook path shipped in July 2022 with GitLab 15.2.0, meaning the hole sat open for roughly 1,753 days before it was closed.
What is at risk
Code execution as the git account is close to full control of a GitLab server. From there an attacker can read every private repository, extract Rails secrets and service credentials, and reach CI/CD pipeline data and deployment tokens. That last part is what turns one compromised server into a supply-chain problem: stolen pipeline secrets can be used to poison builds or push into downstream systems, the same escalation logic we covered when a single credential leak cascaded into further break-ins in the billion-record credential leak. For most companies, the source code and the keys stored beside it are the crown jewels.
Who does this affect?
The exposure is specific to self-managed GitLab — instances a company hosts and updates itself. The affected releases are CE and EE 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1. The fixes are in 18.10.8, 18.11.5 and 19.0.2. GitLab's own SaaS (GitLab.com) is maintained by GitLab and was patched as part of the June update, so hosted users need take no action. Very old releases (15.2 through 18.9) are out of security maintenance entirely and require migration to a supported version, not just a patch.
How to protect your server and data
Upgrade immediately. Move to 18.10.8, 18.11.5 or 19.0.2 (or newer). There is no validated configuration-only workaround — patching the software is the only real fix.
Do not expose GitLab to the open internet. A code-hosting server rarely needs to be reachable by the whole world. Placing it behind a corporate VPN, so only authenticated staff on the internal network can reach the login page, dramatically shrinks the attack surface and buys time when the next flaw appears. This is standard defence-in-depth for internal developer infrastructure.
Review who has push access. Because the exploit needs only a low-privilege account with push rights, audit your user and token list, remove stale accounts, and rotate any credentials or CI/CD secrets if you suspect the server was reachable while unpatched.
Protect developers on untrusted networks. A VPN does not patch a server-side flaw — only the upgrade does that. But for engineers connecting to internal systems from cafés, airports or shared Wi-Fi, a no-logs VPN encrypts their traffic so no one on the same network can intercept the sessions and tokens they send. LiMP VPN is a no-logs service for iOS and Android — see the features and plans, with more security news on our blog.
Is GitLab.com (the hosted service) affected?
No. GitLab.com is managed by GitLab itself and was patched as part of the 10 June update, so users of the hosted service do not need to do anything. The risk applies to self-managed instances that organisations run on their own servers and that were never updated — precisely because the fix was released silently, without flagging it as a security issue. If you administer such an instance, treat the upgrade as urgent.
Sources
This report is based on reporting by The Hacker News and Security Affairs (July 2026), referencing the technical disclosure and proof-of-concept by depthfirst.