CVE-2026-40683: OpenStack Keystone Auth Bypass Vulnerability

CVE-2026-40683 Overview

A type confusion vulnerability exists in OpenStack Keystone before version 28.0.1 that affects deployments using the LDAP identity backend. The vulnerability stems from improper handling of the user enabled attribute, where the LDAP backend fails to convert string values to boolean when the user_enabled_invert configuration option is set to its default value of False. This flaw allows disabled LDAP users to authenticate and perform actions within the OpenStack environment as if they were enabled.

Critical Impact

Disabled users in LDAP directories can bypass authentication controls and gain unauthorized access to OpenStack services, potentially compromising cloud infrastructure security and data integrity.

Affected Products

• OpenStack Keystone versions prior to 28.0.1
• Deployments using LDAP identity backend without user_enabled_invert=True
• Deployments not using user_enabled_emulation

Discovery Timeline

• April 14, 2026 - CVE-2026-40683 published to NVD
• April 14, 2026 - Last updated in NVD database

Technical Details for CVE-2026-40683

Vulnerability Analysis

This vulnerability is classified as CWE-843 (Access of Resource Using Incompatible Type, also known as Type Confusion). The flaw exists in the _ldap_res_to_model method within the UserApi class of Keystone's LDAP identity backend.

When Keystone queries LDAP for user information, the enabled status of a user is returned as a string value (e.g., "TRUE" or "FALSE"). The code was designed to convert this string to a Python boolean, but the conversion logic was only triggered when the user_enabled_invert configuration option was set to True. When this option is False (the default configuration), the raw string value from LDAP is used directly without conversion.

In Python, any non-empty string is evaluated as truthy in boolean contexts. This means that the string "FALSE" returned by LDAP for disabled users would be treated as a truthy value by Keystone, effectively marking those users as enabled.

Root Cause

The root cause is incomplete conditional logic in the _ldap_res_to_model method. The string-to-boolean conversion for the user enabled attribute was only performed inside a conditional block that checked if user_enabled_invert was True. When the condition was False, the code path that performed the conversion was never executed, leaving the raw LDAP string value in place.

This represents a classic type confusion issue where the expected data type (boolean) differs from the actual data type being processed (string), leading to incorrect security decisions.

Attack Vector

An attacker who has been disabled in the organization's LDAP directory can exploit this vulnerability through the following scenario:

1. The attacker previously had valid credentials in the LDAP directory
2. The administrator disables the user account in LDAP by setting the enabled attribute to "FALSE"
3. The attacker attempts to authenticate to Keystone using their credentials
4. Keystone queries LDAP and receives the enabled attribute as the string "FALSE"
5. Due to the type confusion bug, Keystone treats "FALSE" as truthy (since it's a non-empty string)
6. The attacker is granted access despite being disabled in LDAP

This vulnerability requires network access and valid (though disabled) LDAP credentials. The impact can extend beyond the immediate Keystone service to affect scope of other OpenStack services that rely on Keystone for authentication.

Detection Methods for CVE-2026-40683

Indicators of Compromise

• Authentication events from user accounts that have been disabled in LDAP
• Successful Keystone token issuance for users marked as disabled in the LDAP directory
• Unexpected API activity from accounts that should be deactivated
• Audit log discrepancies between LDAP user status and Keystone authentication records

Detection Strategies

• Compare Keystone authentication logs with LDAP directory user status to identify disabled users who successfully authenticated
• Monitor for authentication events from users whose employment or access has been terminated
• Implement correlation rules between LDAP directory changes and subsequent authentication attempts
• Review Keystone configuration files for user_enabled_invert and user_enabled_emulation settings

Monitoring Recommendations

• Enable verbose logging for Keystone authentication events
• Implement automated comparison between LDAP user status and Keystone token issuance
• Set up alerts for authentication attempts from recently disabled accounts
• Deploy behavioral analytics to detect anomalous access patterns from accounts that should be inactive

How to Mitigate CVE-2026-40683

Immediate Actions Required

• Upgrade OpenStack Keystone to version 28.0.1 or later
• If immediate upgrade is not possible, enable user_enabled_invert=True or user_enabled_emulation as a temporary workaround
• Audit all recent authentication events to identify potential exploitation
• Review and revoke any active tokens for users who should be disabled

Patch Information

The fix is available in OpenStack Keystone version 28.0.1. The patch ensures that the user enabled attribute is properly converted from string to boolean regardless of the user_enabled_invert configuration setting. For technical details on the fix, see the OpenDev Review #958205. Additional information is available in Launchpad Bug #2121152 and Launchpad Bug #2141713.

Workarounds

• Set user_enabled_invert=True in the Keystone configuration to enable the string-to-boolean conversion logic
• Enable user_enabled_emulation to use an alternative method for tracking user enabled status
• Implement additional authentication controls at the network layer to restrict access from disabled users
• Consider using a different identity backend until the patch can be applied

# Configuration workaround in keystone.conf
[ldap]
# Enable user_enabled_invert to force string-to-boolean conversion
user_enabled_invert = True

# Alternative: Enable user_enabled_emulation
# user_enabled_emulation = True
# user_enabled_emulation_dn = cn=enabled_users,dc=example,dc=com