GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: SAML/LDAP auto-linking lets an authenticated user take over an LDAP-backed account

CVSS 8.2CVE-2026-15723Control plane, storage & DevOpscurated

Impact

When OmniAuth SAML and LDAP auto-linking are both enabled, improper sanitization in the LDAP email lookup used during identity linking lets an already-authenticated user bind their SAML identity to someone else's LDAP-backed account, with no action from the target. On a GPU fleet where GitLab holds the CI pipelines, runner registration tokens and deploy credentials that push images and job definitions onto the cluster, taking over an operator or maintainer account is a path into what runs on the nodes. The scope-change in the vector reflects that the compromise lands on the identity provider boundary rather than only GitLab itself. Affects all versions from 10.1 up to the fixed releases.

Who can reach it

Network, authenticated: any user who can log into the GitLab instance. Requires the instance to have both OmniAuth SAML and LDAP auto-linking enabled; instances without that combination are not exposed.

What to do

Upgrade to GitLab 19.3.6, 19.4.3 or 19.5.1 per the patch release. For a self-managed instance this is a package upgrade and a restart of the GitLab services; no node reboot. If the upgrade cannot be scheduled immediately, disabling LDAP auto-linking for OmniAuth removes the precondition.

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.