GitLab Rushes Out Patch for Flaw That Let Strangers Run Code on the Server
The October 12 release fixes a maximum-severity bug in Community and Enterprise Edition. Self-managed installs need to update now.
Key points - GitLab shipped emergency updates on October 12, 2026 for a flaw rated CVSS 10.0, the highest possible severity, that let an unauthenticated attacker run code on a self-managed server. - Fixed versions covering both Community Edition and Enterprise Edition are available via GitLab's patch release page. - The bug sat in CI/CD pipeline handling and was triggered by a specially crafted regular expression, a pattern used to match text. - GitLab.com is already patched and GitLab Dedicated customers don't need to act.
GitLab has patched a flaw in its code-hosting software that let anyone, no account or password required, run commands on the server.
Both the free Community Edition and the paid Enterprise Edition are affected. GitLab is urging every self-managed install to upgrade immediately.
The bug carried a severity score of 10.0 out of 10. Scores that high mean the attacker needs nothing: no login, no user interaction, no local access.
What is the flaw?
The weakness sat in GitLab's CI/CD pipeline handling, the automation feature developers use to build and test their code. According to The Hacker News, an attacker could send a specially crafted regular expression and trick the server into executing arbitrary code.
In plain terms: a stranger on the internet feeds the server a booby-trapped string and ends up running commands on the machine that hosts a company's source code. For most organisations, that machine holds the crown jewels. We covered a 9.9-rated GitLab code-execution bug on 2 October in our story on the AI Gateway flaw, but that one required a logged-in user. This one doesn't.
GitLab hasn't yet published full technical details. The company's policy is to make vulnerability issues public on its tracker 90 days after the patch ships, which puts the detailed write-up in mid-January 2027.
Who needs to act?
Anyone running GitLab on their own servers. GitLab.com, the hosted service, is already on the fixed version. GitLab Dedicated customers, who run on infrastructure GitLab manages for them, don't need to take action.
Everybody else needs to move to one of the patched releases now.
That's sorted now.
What should admins do right now?
Upgrade. GitLab's advisory lists no workaround, which is normal for an unauthenticated code-execution bug. Patching is the fix.
Two practical steps while the upgrade is scheduled:
- Restrict network access to the GitLab web interface so it isn't reachable from the open internet, if your setup allows it.
- Review CI/CD job logs and audit logs for anything odd in the days before the patch. A 10.0 flaw in widely deployed software attracts scanner traffic fast.
Should you worry?
The 90-day silence on technical detail buys defenders time, but not much. Proof-of-concept code for GitLab bugs tends to surface within days once researchers diff the fix. This is the third urgent patch call for self-managed GitLab installs we've reported since late September, following the two critical flaws on 17 September and the AI Gateway issue. If you're running GitLab on your own hardware, the honest answer is that your weekend plans just changed.
