Live › vulnerability › CVE-2026-15723
Go to dashboardWhen OmniAuth SAML and LDAP auto-linking are both enabled, an authenticated GitLab user can take over an existing LDAP-backed account. The flaw is improper input sanitization in the LDAP email lookup used during OmniAuth identity linking, and no action from the victim is needed.
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 CE or EE instances from 10.1 up to the fixed releases that have both OmniAuth SAML and LDAP auto-linking enabled. Instances without both features enabled, and GitLab.com-style managed hosting handled by the vendor, are not described as exposed by the sources.
No product ranges from the sources yet.
grep -i -A3 'omniauth' /etc/gitlab/gitlab.rb and check whether SAML is enabled.gitlab.rb for LDAP auto-linking settings (auto_link_ldap_user or equivalent) being enabled.gitlab-rake gitlab:env:info and compare against the fixed versions.19.3.6, 19.4.3, or 19.5.1 depending on the release line you run.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 CE/EE affecting all versions from 10.1 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when OmniAuth SAML and LDAP auto-linking were both enabled, an authenticated user could have taken over an existing LDAP-backed account without any interaction from the targeted user, due to improper input sanitization in the LDAP email lookup path used during OmniAuth identity linking.
This page as .md · .json · in your agent: get_signal("CVE-2026-15723")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.