CVE-2026-16255: GitLab EE incomplete enforcement of instance-wide SAML/LDAP membership lock

The instance-wide SAML or LDAP membership lock exists so that group and project membership comes only from the identity provider. The flaw is in how it was enforced: requests created before the lock was enabled were not blocked afterward. A pending invitation or access request from that period could still be granted or accepted once the lock was on.

The attacker must be an authenticated user. The CVSS vector sets high attack complexity, because the pending request has to exist from before the lock was enabled. The outcome is membership in a project or group that the identity provider did not approve. That can give access to repositories and CI/CD data at the role level granted, and it weakens the audit trail that ties access to your identity provider.

The flaw affects only GitLab EE instances that use the lock. Instances that never enabled it are not in scope. GitLab's notice does not describe exploitation in the wild, and this entry is not in CISA's KEV catalog.

GitLab EE from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. The notice does not name fixes for older branches such as 19.2.x, so confirm those with GitLab. Find your version in the GitLab UI help page or the admin overview; GitLab documents this under "Find your GitLab version".

Then check whether the SAML or LDAP membership lock is enabled in your instance settings. The product listing is GitLab CE/EE, but the advisory names EE.

Upgrade to GitLab 19.5.1, 19.4.3 or 19.3.6, matching your release line. The patch release notice names no workaround. It also says the release includes regular migrations in 19.4.3 and 19.3.6 and a post-deploy migration in 19.4.3. Single-node instances have downtime during the upgrade, and multi-node instances can use zero-downtime procedures. This entry is not in the KEV catalog, so there is no CISA due date.

Review group and project membership against your identity provider, looking for members added since the lock was enabled who are not in the IdP groups. Check the audit events for membership additions, invitation acceptances and access request approvals dated after the lock was switched on, and check any invitations or requests that predate it. Remove members the identity provider did not approve.

When the instance-wide SAML or LDAP membership lock was enabled, an authenticated user could have granted or accepted project and group membership outside the identity provider's control, due to incomplete enforcement of the membership lock on requests created before the lock was enabled. Impacted versions: GitLab EE all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. Fixed in GitLab CE/EE 19.5.1, 19.4.3 and 19.3.6, released October 21, 2026.