GPU VulnDB

Database/Control plane, storage & DevOps

GitLab CE/EE: crafted CI/CD regex lets an unauthenticated user run code on the GitLab server

CVSS 10.0CVE-2026-97229Control plane, storage & DevOpscurated

Impact

An unauthenticated attacker can execute arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration, scored 10.0 with a scope change. For a GPU fleet this is the build-and-deploy brain: a self-managed GitLab typically holds the registry credentials, Kubernetes deploy tokens, runner registration tokens and model-pipeline secrets used across the cluster, so server-side code execution converts directly into the ability to push poisoned container images and job definitions onto GPU nodes. Compromise of the CI server also means every subsequent training or serving deployment must be treated as suspect until images are rebuilt from a known-good state.

Who can reach it

Anyone who can reach the GitLab web interface, with no authentication required. Instances exposed to the internet or to a broad corporate network are directly reachable; the only real mitigation before patching is to restrict network access to the GitLab front end.

What to do

Upgrade to GitLab 19.2.8, 19.3.5 or 19.4.2 (or later) per the 19.4.2 patch release. This is a package upgrade plus service restart of the GitLab application - CI jobs in flight will be interrupted, but no GPU node needs to be drained. Because the flaw is pre-authentication RCE, rotate runner registration tokens, CI variables and registry credentials on any instance that was internet-reachable before the upgrade.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.