CVE-2026-15723: 
GitLab 脆弱性分析と緩和策

CVE-2026-15723 is an LDAP injection vulnerability in GitLab CE/EE that allows an authenticated attacker to take over any existing LDAP-backed account without interaction from the targeted user. The flaw exists when both OmniAuth SAML and LDAP auto-linking are enabled, due to improper input sanitization in the LDAP email lookup path used during OmniAuth identity linking. It affects all versions from 10.1 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 (both Community and Enterprise editions). It was published on October 22, 2026, and carries a CVSS v3.1 base score of 8.2 (High) (ENISA EUVD, GitLab Patch Release).

The root cause is classified as CWE-90 (Improper Neutralization of Special Elements used in an LDAP Query — 'LDAP Injection'), mapped to CAPEC-136. When a GitLab instance has both OmniAuth SAML and LDAP auto-linking enabled, the LDAP email lookup performed during OmniAuth identity linking does not properly sanitize user-supplied input, allowing an attacker to manipulate the LDAP query. By crafting a malicious SAML assertion or identity-linking request, an authenticated attacker can cause GitLab to resolve their identity to a different LDAP-backed account, effectively hijacking it. Exploitation requires the attacker to already hold a GitLab account and the target instance to have both OmniAuth SAML and LDAP auto-linking configured simultaneously (ENISA EUVD, GitLab Patch Release).

Successful exploitation grants the attacker full control over any targeted LDAP-backed GitLab account without requiring any action from the victim. This results in high confidentiality and integrity impact — the attacker can access private repositories, CI/CD secrets, API tokens, and sensitive project data belonging to the hijacked account, and can make unauthorized changes to code, pipelines, or settings. Availability is not directly impacted. The scope is changed, meaning the impact extends beyond the attacker's own account to other users' accounts on the same instance (ENISA EUVD).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (ENISA EUVD). A GitHub repository (github.com/emirwtz/CVE-2026-15723) appeared shortly after disclosure, though its contents and reliability are unverified. The EPSS score is approximately 0.334%, indicating a low but non-negligible probability of exploitation in the near term. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires a low-privilege authenticated account and high attack complexity, limiting opportunistic mass exploitation but not targeted attacks against high-value GitLab instances (ENISA EUVD, GitLab Patch Release).

1. Reconnaissance: Identify a GitLab CE/EE instance (version 10.1–19.5.0) that has both OmniAuth SAML and LDAP auto-linking enabled. This configuration is often visible through login page UI elements (e.g., a SAML SSO button) or can be inferred from organizational context.
2. Obtain a low-privilege account: Register or use an existing authenticated GitLab account on the target instance.
3. Identify a target LDAP-backed account: Determine the email address of a high-value LDAP-linked user (e.g., an administrator) through public project membership, commit history, or other enumeration.
4. Craft a malicious SAML assertion or identity-linking request: Manipulate the OmniAuth identity-linking request to inject LDAP special characters (e.g., *, (, ), \, NUL) into the email field used for the LDAP lookup, causing the query to match the target user's LDAP entry instead of the attacker's.
5. Trigger account takeover: Submit the crafted request to the GitLab OmniAuth SAML callback endpoint. If successful, GitLab links the attacker's session to the target LDAP account, granting full access.
6. Post-exploitation: Access the victim's repositories, secrets, CI/CD pipelines, and administrative functions as the hijacked user (ENISA EUVD).

• Logs: GitLab application logs (production.log) showing OmniAuth SAML callback requests (/users/auth/saml/callback) from one user session that result in a session being associated with a different LDAP UID or email than expected; repeated or anomalous identity-linking events for the same LDAP account from different source identities.
• Logs: Audit log entries showing an account's linked identities changing unexpectedly, or a user logging in via SAML who was not previously SAML-linked.
• Network: Unusual POST requests to /users/auth/saml/callback containing LDAP special characters (*, (, ), \, \00) in email or UID fields.
• Behavioral: A user account suddenly gaining access to projects or groups they were not previously a member of; administrative actions performed by accounts that do not match expected administrator behavior patterns.

GitLab has released patched versions: 19.3.6, 19.4.3, and 19.5.1 for CE and EE. Administrators should upgrade to the appropriate fixed version immediately (GitLab Patch Release). As a temporary workaround if patching is not immediately possible, disable either OmniAuth SAML or LDAP auto-linking in the GitLab configuration — the vulnerability only exists when both features are simultaneously enabled. Additionally, review GitLab audit logs for suspicious OmniAuth identity-linking activity to detect any potential account takeovers that may have already occurred (ENISA EUVD).

The disclosure generated notable coverage across security media, with outlets such as CyberSecurityNews, GBHackers, Heise, and InfoWorld reporting on the patch release (Heise). Coverage was often bundled with a separate, higher-severity GitLab RCE vulnerability (CVE-2026-110264, CVSS 10.0) disclosed in the same patch cycle, which drew more attention and may have overshadowed CVE-2026-15723 in public discourse. Security community commentary on Mastodon and Bluesky noted the 12-year exposure window (since version 10.1) as particularly concerning for long-running self-managed GitLab deployments. Forkast.news highlighted the account takeover as an example of "trusted input nobody checked" in authentication flows (Forkast).