LDAP disabled-user auth bypass fixed in OpenStack Keystone
TL;DR — OpenStack Keystone’s LDAP identity backend can mis-handle the “enabled/disabled” LDAP attribute, allowing LDAP-disabled users to authenticate and operate as if enabled.
What happened
OpenStack Keystone is the Identity service used to authenticate users and issue tokens for OpenStack APIs, often backed by enterprise LDAP directories.
CVE-2026-40683 describes a logic bug in Keystone’s LDAP identity backend when user_enabled_invert is set to False (the default): Keystone fails to convert the LDAP “enabled” attribute to a boolean and instead uses the raw LDAP string (e.g., "FALSE"). In Python, non-empty strings are truthy, so users marked as disabled in LDAP can be treated as enabled, allowing them to authenticate and perform actions.
| Item | Source value |
|---|---|
| Vulnerability class | Disabled-account policy bypass / improper enabled-attribute handling |
| CWE | CWE-843 |
| Severity | CVSS v3.1 7.7 (High) |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:H |
Why this matters: identity backends are a shared control plane dependency—when the “disabled user” contract is broken, offboarding and incident containment procedures (disable in LDAP) stop being reliable across the cloud.
Who is impacted
- OpenStack deployments using Keystone’s LDAP identity backend.
- Specifically, deployments without
user_enabled_invert=Trueand withoutuser_enabled_emulationconfigured.
| Keystone line (per CVE record) | Affected versions | Patched versions (implied by affected ranges) |
|---|---|---|
| 8.x through 24.x | >= 8.0.0 and < 25.0.1 | 25.0.1 and later |
| 26.x | >= 26.0.0 and < 26.1.1 | 26.1.1 and later |
| 27.x | >= 27.0.0 and < 27.0.1 | 27.0.1 and later |
| 28.x | >= 28.0.0 and < 28.0.1 | 28.0.1 and later |
What to do now
- Follow vendor remediation guidance and apply a Keystone release that includes the fix for CVE-2026-40683.
- Use the affected/patched ranges above to scope upgrades across your fleet (control plane nodes, containers/images, and any pinned distro packages).
- If you cannot patch immediately, the OpenStack OSSA write-up referenced by the CVE lists a workaround:
"To work around this vulnerability, set user_enabled_invert=True ... or use user_enabled_emulation"
- Treat this as an identity-control failure: if you have relied on “disable in LDAP” as an emergency response lever, validate (in staging, then prod) that disabled users can no longer obtain tokens after mitigation, and audit for any unexpected logins by supposedly-disabled LDAP accounts.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.