GPU VulnDB

Database/Control plane, storage & DevOps

GitLab EE: membership lock not enforced on pre-existing requests, letting users grant access outside the IdP

CVSS 7.1CVE-2026-16255Control plane, storage & DevOpscurated

Impact

With the instance-wide SAML or LDAP membership lock enabled, GitLab EE from 12.0 before 19.3.6, 19.4.3 and 19.5.1 still honored project and group membership requests created before the lock was turned on, so an authenticated user could grant or accept membership that the identity provider was supposed to control. An operator who turned the lock on to make the IdP the single source of truth for repository and pipeline access does not actually have that guarantee, which matters where GitLab holds the manifests, runner configuration and deploy credentials for the fleet.

Who can reach it

Any authenticated GitLab user with a membership request that predates the lock being enabled. Network access to the GitLab instance plus a normal account.

What to do

Upgrade to GitLab EE 19.5.1, 19.4.3 or 19.3.6 and restart the instance; a self-managed upgrade and service restart, no node maintenance. Afterwards audit existing group and project memberships against the identity provider, since memberships already granted through this path are not revoked by the fix.

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.