GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: MCP-scoped tokens can act beyond their intended scope

CVSS 5.4CVE-2026-92874Control plane, storage & DevOpscurated

Impact

Improper authorization checks let an authenticated user holding an MCP-scoped token perform actions the token's scope was not meant to permit. MCP tokens are the credential handed to LLM agents and agent tooling wired into a self-hosted GitLab, so the practical exposure is an agent integration - or anyone who obtains its token - reaching repository or project operations the operator deliberately fenced off when issuing it. On a fleet where GitLab is the CI/CD control plane for cluster manifests and model pipelines, scope creep on an automation credential is a change-control problem. The advisory rates it low confidentiality and integrity impact and does not describe which actions become reachable.

Who can reach it

An authenticated GitLab user or automation holding an MCP-scoped token, over the network to the GitLab instance. No admin role needed.

What to do

Upgrade self-managed GitLab to 19.2.7, 19.3.3, or 19.4.1 depending on your branch (all versions from 18.3 are affected). This is the standard GitLab patch release: package upgrade plus a service restart and migrations on the GitLab host, no cluster-wide disruption. GitLab.com is already patched. Consider rotating MCP-scoped tokens after upgrading.

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.