GPU VulnDB

Database/Control plane, storage & DevOps

GitLab EE: Owner or Maintainer can silently disable protected-environment deployment approvals

CVSS 4.4CVE-2026-86341Control plane, storage & DevOpscurated

Impact

Access control on protected environments was checked after the resource had already been modified, so a user with Owner or Maintainer permissions could turn off deployment approval requirements without the change being blocked or surfaced. Unapproved deployments then reach production. Where GitLab environments gate deploys to a GPU cluster - node images, driver rollouts, GPU Operator or model-serving manifests - this removes the four-eyes control on exactly the changes that can take a fleet down, and it does so quietly. It requires a high-privilege account already, so the realistic threat is a compromised maintainer credential or an insider, not an outside attacker.

Who can reach it

An authenticated GitLab EE user with Owner or Maintainer permissions on the group or project, over the network. High privilege required.

What to do

Upgrade self-managed GitLab EE to 19.1.8, 19.2.6, or 19.3.2 (affected from 17.1). Package upgrade and service restart on the GitLab host. After upgrading, audit protected-environment approval settings and recent deployments for approval rules that were disabled while the flaw was live.

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.