GitLab EE CVE-2026-16255

Exploitation requires that the instance-wide SAML or LDAP membership lock feature is ENABLED on a GitLab EE instance (not Community Edition), and that a project/group membership request or invitation was created BEFORE that lock was enabled - the flaw is incomplete enforcement of the lock on pre-existing requests. The attacker must be an authenticated user (PR:L) with a relevant pending membership action. Limiting factors: this does not affect default/CE installs, does not work against requests created after the lock is active, needs no user interaction but is state-dependent (hence CVSS AC:H), and confers unauthorized project/group membership rather than full administrative takeover.

This is a genuine but moderate-priority authorization flaw, not a drop-everything emergency. The provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N, base 5.9) is internally consistent with the description: network-reachable (AV:N), requires an authenticated low-privilege user (PR:L), needs no victim interaction (UI:N), but carries high attack complexity (AC:H) because exploitation only works against project/group membership requests that were created BEFORE the instance-wide SAML/LDAP membership lock was enabled - a narrow, timing/state-dependent precondition rather than a repeatable condition on default installs. POC/exploit code is publicly referenced (HackerOne #3809350), so exploitability is demonstrated, but there is no CISA KEV entry and no EPSS score supplied, meaning there is no evidence of active or widespread exploitation. The high-confidence signals (vendor-reported by GitLab, patched across maintained branches, public POC) point to a credible, bounded insider/low-privilege escalation rather than a mass-exploited internet threat. Net: real and worth patching on normal cadence for affected EE instances that actually use membership lock, but the AC:H precondition and absence of KEV/EPSS argue against treating it as a high-urgency widespread risk. Note the signals are not conflicting - they consistently describe a conditional, authenticated-only issue.

On a GitLab EE instance where instance-wide SAML or LDAP membership lock is enabled to centralize access through the identity provider, an authenticated low-privilege user who had a pending project or group membership request (or invite) created before the lock took effect grants or accepts that membership, bypassing the IdP's control over group/project access. A public exploit write-up exists (HackerOne #3809350), demonstrating the bypass, though the pre-lock request precondition limits reliable reproduction.