On October 21, GitLab shipped a critical patch release for CVE-2026-110264, rated CVSS 10.0. It allows unauthenticated remote code execution and affects self-managed Community Edition (CE) and Enterprise Edition (EE) from version 7.0 onward.
Fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, and GitLab.com and GitLab Dedicated are already patched. The advisory does not mention exploitation in the wild, and GitLab has published two threat detections for self-managed instances. SlowMist CISO 23pds (@im23pds) has urged teams to upgrade.
Where small teams are exposed
Process
Self-hosted GitLab is often set up by an early engineer and then left alone. It sits years behind, and when a patch lands nobody owns the upgrade or its deadline.
Risk
For remote work, GitLab is often reachable from the internet. With a flaw that needs no login, scanning and intrusion follow quickly once exploit code circulates.
Privileges
GitLab holds source code, CI/CD variables, deploy keys and cloud credentials. Losing the server means losing the release pipeline, and an attacker can tamper with what ships.
Five things you can do now
- Today, check your self-managed GitLab version, upgrade to the fixed release for your branch, and record when it is done
- Until the upgrade is complete, move GitLab behind your internal network or a zero-trust gateway, reachable only via VPN or allowlisted IPs
- Audit secrets in CI/CD variables and on runners, remove anything tied to funds or signing, and re-grant the rest with least privilege
- Enable GitLab's threat detections and review recently added admin accounts, access tokens, deploy keys and webhooks; revoke anything unexpected
- Assign an owner for code hosting and CI, subscribe to official security advisories, and commit to handling critical flaws within 24 hours
Affected versions, fixed versions and detections follow GitLab's official patch release. This article does not cover exploitation details.
