GitLab Patches a Critical Hole That Reaches Back to 2014
A second emergency fix in nine days covers every self-managed install since version 7.0, and the first round missed older branches.
Key points
- GitLab released emergency patches on October 21, 2026 for a flaw that lets an attacker run commands on a self-managed server without logging in, affecting every release since version 7.0 from 2014.
- A patch nine days earlier, on October 12, covered only versions 19.2 and later, leaving older branches exposed until this round.
- GitLab.com and Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later already carry the fix; only self-managed admins need to act.
- Threat Vectr's own leak-site tracking has logged a steady rise through 2026 in ransomware crews listing victims whose first foothold came through source-code and developer tooling.
GitLab, the code-hosting platform used by companies to store and build their software, has pushed a second emergency update in nine days. The flaw it fixes lets an attacker reach a self-managed server over the network and run commands on it without ever logging in. That's as bad as it gets.
GitLab says every self-managed install should move to one of these immediately. GitLab.com, the hosted service most individual developers use, is already patched.
The vulnerable code goes back to GitLab 7.0, shipped in 2014. Any organisation still running a self-managed server on an older branch has been exposed for more than a decade.
Why a second patch so soon?
The first one didn't go far enough. GitLab shipped an earlier emergency fix on October 12, but it only covered the 19.2 branch and newer. The October 21 builds sit one patch above the October 12 ones, so even a server patched nine days ago needs updating again.
That's a messy sequence, and it's the detail worth flagging. An admin who did the right thing on October 12 isn't done. We covered that first emergency release on 13 October in "GitLab Rushes Out Patch for Flaw That Let Strangers Run Code on the Server", when the fix reached only the newer branches. The Hacker News put the common vulnerability scoring system (CVSS, a standard 0-to-10 scale for severity) rating at 10.0, the maximum. GitLab's own advisory doesn't dispute the severity.
Who actually has to do something?
Self-managed GitLab administrators, and only them. If your company runs its own GitLab server inside its network, it needs patching this week. Pay for the hosted SaaS version at gitlab.com, or run GitLab Dedicated at 19.3.5-internal0 or 19.4.2-internal0 or later, and the fix is already in place.
| Branch | Fixed version |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
GitLab also publishes guidance on what to watch for in your own logs if you suspect someone got in before you patched. For a flaw this old, that check isn't optional.
What this means for ordinary users
Nothing you type on your laptop needs changing. The risk is to the organisations whose developers push code to a private GitLab server, and to the customers of those organisations further down the line.
Source-code servers are a quiet favourite with ransomware crews. Get into one and you can read the software a company is about to ship, lift credentials left in by careless developers, and sometimes slip changes into a build that then rolls out to customers. Threat Vectr's own tracking of ransomware leak sites through 2026 shows a steady drip of victims where criminals claimed the way in was developer tooling rather than a user's email. None of those listings have been tied to this specific flaw, and it's too early for them to be. Give it a month.
