Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged GitLab user
-
DeliveryInitiate OmniAuth SAML identity linking
-
ExploitInject crafted input into LDAP email lookup
-
ExecutionResolve lookup to victim LDAP account
-
ImpactLink attacker identity, take over account
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization LDAP query parameterization
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that BOTH OmniAuth SAML authentication AND LDAP auto-linking are enabled on the GitLab instance - a specific, non-default combination; instances without both features configured are not affected. The attacker must be an authenticated GitLab user (PR:L), but no interaction from the targeted victim is needed (UI:N), and the account takeover affects any existing LDAP-backed account. The AC:H rating indicates meaningful attacker effort or conditions beyond pure default exploitation. Limiting factors for defenders: the dual-feature prerequisite sharply narrows the vulnerable population, authentication is required, and only instances on affected versions below 19.3.6 / 19.4.3 / 19.5.1 are in scope. |
| Impact | This is a credible, above-average priority for organizations running GitLab with the specific affected configuration, but it is not a drop-everything emergency. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N, score 8.2) shows a network-reachable flaw requiring only low privileges (any authenticated user) and no victim interaction, yielding high confidentiality and integrity impact with a scope change - consistent with full takeover of another user's LDAP-backed account. The AC:H rating is the key tempering signal: successful exploitation is non-trivial and hinges on a precise condition (both OmniAuth SAML and LDAP auto-linking enabled). Publicly available exploit code exists (referenced HackerOne report #3852192), which raises practical risk, but this is distinct from active exploitation: there is no CISA KEV listing and no EPSS score in the provided data, so real-world exploitation volume cannot be quantified from these inputs. No SSVC decision record was provided. Net: treat as high-severity for environments matching the vulnerable config, moderate elsewhere, with the non-default dual-feature requirement and AC:H meaningfully narrowing the exposed population versus the raw 8.2 score. EPSS and KEV data are both absent and should be checked directly before final prioritization. |
| Exploit ScenarioDerived | In a GitLab instance where both OmniAuth SAML and LDAP auto-linking are enabled, a low-privileged authenticated attacker initiates OmniAuth identity linking and supplies crafted input that is passed unsanitized into the LDAP email lookup query. Because of the improper input neutralization (CWE-90), the lookup resolves to a targeted victim's LDAP-backed account and links the attacker's identity to it, resulting in takeover with no interaction from the victim. Public exploit code for this flow is available via the referenced HackerOne report. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 22, 2026
An authenticated GitLab user can seize control of an existing LDAP-backed account on instances that have both OmniAuth SAML and LDAP auto-linking enabled, because the LDAP email lookup performed during OmniAuth identity linking does not properly sanitize input. GitLab CE/EE deployments from 10.1 up to (but excluding) 19.3.6, 19.4.3, and 19.5.1 are in scope; the attacker needs a valid account (PR:L) but no action from the victim (UI:N), and the compromise extends beyond the attacker's original security scope (S:C) with high confidentiality and integrity impact while availability is unaffected (CVSS 8.2). Publicly available exploit code exists and a HackerOne report documents the issue, though there is no CISA KEV confirmation of active exploitation; the dual-feature prerequisite (SAML plus LDAP auto-linking) sharply narrows the exposed population, so this is a high-priority fix for that specific configuration rather than a universal emergency.
RemediationAI
Vendor-released patch: upgrade to GitLab 19.3.6, 19.4.3, or 19.5.1 depending on your release line - these are the versions named in the GitLab patch release notice (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/), and full technical detail is in https://gitlab.com/gitlab-org/gitlab/-/work_items/605977. Where an immediate upgrade is not possible, the most effective compensating control is to disable LDAP auto-linking (or the OmniAuth SAML provider) so the vulnerable identity-linking path is never exercised; the trade-off is that users lose automatic account matching and must be provisioned or linked manually, which adds administrative overhead and can cause login friction for existing LDAP users. Restricting outbound/administrative access to the SAML and LDAP integration configuration pages reduces the chance of the feature combination being re-enabled inadvertently. Because public exploit code exists (HackerOne report 3852192), prioritize patching any instance that actually has both SAML and LDAP auto-linking enabled, and audit existing LDAP-backed accounts' linked identities for unauthorized SAML identities created before the fix; instances without both features configured can be scheduled at normal patch cadence.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-90 (LDAP injection) in GitLab's OmniAuth identity-linking flow. When OmniAuth SAML is enabled together with LDAP auto-linking, GitLab resolves an incoming identity to an existing LDAP-backed account by looking up the user-supplied email attribute against the directory. That lookup path fails to sanitize the input before constructing the LDAP query/filter, so a crafted value can alter the query semantics and cause the identity to be linked to an account the attacker does not own. This is a binding/logic flaw rather than a memory-safety issue: the SV:C rating reflects that the resulting takeover crosses a privilege boundary from the attacker's own account into a different LDAP-backed identity, with C:H/I:H because the attacker inherits the victim's repositories, groups, and permissions. AC:H reflects the conditions required - both features configured, a victim account present, and crafted input that survives the linking flow. The affected CPE is gitlab:gitlab across all editions (CE and EE) for the whole version span from 10.1 onward. Related tags in the source data mention code injection and information disclosure, but the authoritative vector and description point squarely at LDAP filter injection during account linking.
Know when Saml gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
Network-reachable (AV:N) but gated by the non-default SAML+LDAP-auto-linking combination and precise injection (AC:H); any authenticated user suffices (PR:L); taking over a separate account is a scope change (S:C) with high C/I and no availability impact.
Primary rating from Vendor (GitLab).
CVSS VectorVendor: GitLab
Lifecycle Timeline
2DescriptionCVE.org
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.
Executive ViewAI
A flaw in GitLab CE/EE (versions 10.1 through the 19.3.6 / 19.4.3 / 19.5.1 release boundaries) allows any user holding a valid GitLab account to take over someone else's existing LDAP-backed account, but only on instances where both OmniAuth SAML and LDAP auto-linking are enabled concurrently. The attacker gains access well beyond their own permission scope, with high confidentiality and integrity impact and no availability impact, meaning an insider or low-privilege user could impersonate higher-privileged colleagues and read or alter their work. Leadership should care because this is an identity-compromise risk concentrated in a specific, identifiable configuration subset of our GitLab estate rather than a universal exposure, so scoping and remediation can be targeted and fast.
No vendor-released patch identified at time of analysis, so interim mitigations are configuration-based: disable LDAP auto-linking and/or the OmniAuth SAML provider on affected instances (the exploit requires both), restrict SAML identity linking to a small trusted administrator population, enforce MFA on all LDAP-backed accounts, control and monitor who can write to LDAP email attributes used during linking, audit existing OmniAuth identities for links that do not match HR-verified ownership, and alert on identity-link creation and authentication from unexpected source addresses. Upgrading to the stated boundary releases 19.3.6, 19.4.3, or 19.5.1 should be scheduled as the durable fix.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
A signature verification vulnerability exists in crewjam/saml. Rated critical severity (CVSS 9.8), this vulnerability is
Unauthenticated remote attackers can bypass authentication in Apache WSS4J (4.0.0 before 4.0.2, 3.0.0 before 3.0.6, and
SQL injection in Okta Access Gateway versions prior to 2026.9.1 allows a participant in the SAML federation/authenticati
ComponentSpace.Saml2 4.4.0 Missing SSL Certificate Validation. Rated critical severity (CVSS 9.8), this vulnerability is
A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All versions >= V1.17.3 < V1.18.0), Mendix SAM
The crewjam/saml go library prior to version 0.4.9 is vulnerable to an authentication bypass when processing SAML respon
A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All versions < V1.17.0), Mendix SAML (Mendix 7
A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All versions < V1.17.0), Mendix SAML (Mendix 8
Jenkins SAML Plugin 2.0.7 and earlier allows attackers to craft URLs that would bypass the CSRF protection of any target
A vulnerability has been identified in Mendix SAML Module (All versions < V2.1.2). Rated high severity (CVSS 8.8), this
Unauthenticated network attackers can potentially take over Oracle Access Manager 12.2.1.4.0 and 14.1.2.0.0 through craf
Improper authentication in the SAML SSO identity-linking flow of self-hosted Sentry 26.5.0 through 26.7.1 lets an attack
EUVD-2026-107677
GHSA-92f3-3rm4-rcgv
NVD
CVE.org
EPSS
Exploit-DB