GPU VulnDB

Database/Control plane, storage & DevOps

GitLab EE: authenticated user with certain permissions can hijack another project's CI runners

CVSS 8.8CVE-2025-11702Control plane, storage & DevOpscurated

Impact

An authenticated attacker holding specific project permissions can take over runners registered to projects they do not own. A hijacked runner executes the attacker's job definitions on the victim project's executor, which in a GPU shop is a privileged build host or a GPU-equipped CI node with registry push credentials, cloud tokens and cached source. That turns a permissions bug in the SCM into code execution on fleet infrastructure and a route into other teams' pipelines. GitLab scores it high on all three of confidentiality, integrity and availability.

Who can reach it

An authenticated GitLab user with specific project permissions - no administrator access needed. GitLab EE only; CE is not listed as affected.

What to do

Upgrade to GitLab 18.3.5, 18.4.3 or 18.5.1 depending on your branch; all EE versions from 17.1 up to those are affected. This is a GitLab application upgrade and service restart, not a fleet-wide maintenance window. Afterwards, review which runners are registered where and rotate credentials held by any runner that could have been hijacked.

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.