Executive Summary

This vulnerability exists in OpenStack Keystone versions before 28.0.1 when using the LDAP identity backend. The issue is that the system does not properly convert the user enabled attribute from LDAP to a boolean value when the configuration option user_enabled_invert is set to False (which is the default). Instead of converting strings like "FALSE" to a boolean False, the raw string is used directly. Since non-empty strings are considered True in Python, users who are actually disabled in LDAP are mistakenly treated as enabled by Keystone, allowing them to authenticate and perform actions.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow users who are supposed to be disabled in the LDAP directory to still authenticate and access the OpenStack Keystone service. This means unauthorized users may gain access to resources and perform actions they should not be permitted to, potentially leading to unauthorized access, data breaches, or disruption of services.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability in OpenStack Keystone's LDAP identity backend causes disabled users in LDAP to be incorrectly treated as enabled, allowing them to authenticate and perform actions. This flaw undermines access control mechanisms by permitting unauthorized access.

Such unauthorized access can lead to violations of compliance requirements in standards and regulations like GDPR and HIPAA, which mandate strict access controls and protection of sensitive data. If disabled users can authenticate and access resources, it may result in unauthorized data exposure or modification, thereby compromising regulatory compliance.

Therefore, this vulnerability poses a risk to organizations relying on Keystone with LDAP backend for identity management, as it can lead to non-compliance with data protection and privacy regulations due to improper enforcement of user enablement status.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate CVE-2026-40683, you should update your OpenStack Keystone deployment to a fixed version, such as the Gazpacho (29.0.0) release or later, where the issue has been resolved.

As an immediate workaround, you can set the configuration option `user_enabled_invert` to True and use an LDAP attribute with inverted semantics (e.g., `nsAccountLock`).

Alternatively, enable the `user_enabled_emulation` option to manage user enabled status based on group membership instead of relying on the problematic LDAP attribute.

These configuration changes ensure that disabled users in LDAP are correctly recognized as disabled by Keystone, preventing unauthorized authentication.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the incorrect interpretation of the LDAP 'enabled' attribute in OpenStack Keystone's LDAP identity backend, causing disabled users to be treated as enabled. Detection involves verifying the configuration and behavior of the LDAP backend in Keystone.

To detect if your system is vulnerable, check the Keystone LDAP configuration for the following settings:

• Ensure the configuration option `user_enabled_invert` is set to False (the default), which is vulnerable.
• Check if `user_enabled_emulation` is disabled (False), which means the vulnerability applies.

You can also test whether disabled users in LDAP are incorrectly allowed to authenticate by attempting to authenticate with a user known to be disabled in LDAP.

Suggested commands to help detect the vulnerability include:

• Inspect Keystone LDAP configuration file (e.g., `/etc/keystone/keystone.conf`) for the relevant options: `user_enabled_invert`, `user_enabled_emulation`, and `user_enabled_attribute`.
• Use OpenStack CLI or API to attempt authentication with a user disabled in LDAP and observe if authentication succeeds.
• Query LDAP directly to verify the 'enabled' attribute values for users, for example using ldapsearch:
• ```ldapsearch -x -b "<user_base_dn>" "(uid=<username>)" IsActive```
• Check Keystone logs for authentication events of disabled users.

No specific detection commands are provided in the resources, but these configuration checks and authentication tests are practical approaches to detect the vulnerability.

Useful 0 Not Useful 0