Live › vulnerability › CVE-2026-16255
Go to dashboardWhen the instance-wide SAML or LDAP membership lock is enabled, requests created before the lock was turned on can still grant or accept project and group membership outside the identity provider's control. An authenticated user can use this to gain access to projects and groups they should not be able to join.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Self-managed GitLab EE instances from 12.0 up to the fixed versions that have the instance-wide SAML or LDAP membership lock turned on. The issue requires that the lock was enabled after some membership requests already existed. GitLab.com and instances without the lock enabled are less exposed; the sources do not say how GitLab.com is handled.
No product ranges from the sources yet.
gitlab-rake gitlab:env:info or the admin Version page; affected if below 19.3.6, between 19.4 and 19.4.2, or between 19.5 and 19.5.0 on EE installs19.3.6, 19.4.3, or 19.5.1 (or later on the same line)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, 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.
This page as .md · .json · in your agent: get_signal("CVE-2026-16255")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.