Red Hat 389 Directory Server SASL identity confusion enables Directory Manager privilege escalation

A flaw was found in 389 Directory Server. During SASL PLAIN authentication, a stale identity carried in a Cyrus SASL auxiliary property from a prior failed bind attempt can be installed on a connection following a subsequent, unrelated successful bind, regardless of which SASL mechanism completes that second bind. An attacker can send a SASL PLAIN bind as cn=Directory Manager with an incorrect password, then complete a SASL ANONYMOUS bind on the same connection, causing the server to grant Directory Manager authority without any valid credentials. A variant using a valid low-privileged account's own successful bind instead of an anonymous one is also possible.

Every affected entry in the normalized record has default_status: affected; the record does not provide detailed version ranges. Affected branches include:

• Red Hat Directory Server 11.7 E4S for RHEL 8 and Red Hat Directory Server 11.9 for RHEL 8, package redhat-ds:11.
• Red Hat Directory Server 12.2 E4S for RHEL 9 and Red Hat Directory Server 12.4 E4S for RHEL 9, package redhat-ds:12.
• Red Hat Directory Server 12, package 389-ds-base.
• Red Hat Enterprise Linux 6 Extended Lifecycle Support - EXTENSION and Red Hat Enterprise Linux 7 Extended Lifecycle Support, package 389-ds-base.
• Red Hat Enterprise Linux 8, plus Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, 8.4 Extended Update Support Long-Life Add-On, 8.6 Advanced Mission Critical Update Support, 8.6 Extended Update Support Long-Life Add-On, 8.8 Telecommunications Update Service and 8.8 Update Services for SAP Solutions, using package 389-ds:1.4.
• Red Hat Enterprise Linux 9, plus Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions, 9.4 Update Services for SAP Solutions and 9.6 Extended Update Support, using package 389-ds-base.
• Red Hat Enterprise Linux 10 and Red Hat Enterprise Linux 10.0 Extended Update Support, package 389-ds-base.

The Red Hat errata comments in the record state that the issue has been addressed in each linked product branch. The returned evidence does not identify one exact fixed version for the general Red Hat Directory Server 12 entry.

The flaw is in SASL bind handling in 389-ds-base and is classified as CWE-287, Improper Authentication. The ids_sasl_canon_user() function writes the resolved bind DN into a Cyrus SASL auxiliary property on every canonicalization attempt, including failed attempts. A failed one-shot PLAIN exchange does not recreate the SASL context; a later successful SASL bind on the same connection retrieves the property through prop_getnames() and unconditionally trusts the first value, dnval[0].values[0], without checking the mechanism, value freshness, or whether the value matches the identity just authenticated.

The evidence establishes this high-level sequence:

• A failed SASL PLAIN bind can leave cn=Directory Manager in the auxiliary property.
• A subsequent unrelated successful SASL bind on the same connection can cause the server to retrieve that old DN, including when the second mechanism is SASL ANONYMOUS.
• The server then installs the stale identity instead of the identity actually authenticated and grants Directory Manager authority.

The reported root cause is in ldap/servers/slapd/saslbind.c, specifically ids_sasl_canon_user() and ids_sasl_check_bind(). The returned evidence does not describe the internal patch implementation, such as how the auxiliary property is refreshed or cleared.

The flaw is remotely reachable over a connection that Red Hat describes as LDAPS. The credential-free variant requires no valid account and no user interaction. The key precondition is that the server permits SASL PLAIN among its configured authentication mechanisms; Red Hat states that no non-default configuration is required for the flaw to occur. A second variant requires a valid low-privileged account and uses that account's own successful bind as the second step.

The supplied evidence records an isolated confirmation by Red Hat in a sandbox, but it does not confirm a public exploit or real-world exploitation campaign. The record marks public_exploit as false and provides no known-exploited status; this should not be interpreted as proof that exploitation has never occurred.

The technical result is that the server can install an old, highly privileged DN instead of the identity authenticated by the current bind. In the credential-free variant, a remote attacker can obtain Directory Manager authority; in the other variant, a low-privileged account can be escalated on the same connection. That authority may allow directory data access, directory or service configuration changes and disruption of dependent services.

The practical scope is limited to servers and package branches containing the vulnerable code, and to deployments where SASL PLAIN is permitted so the stale identity can be planted. The record does not establish that every Directory Manager operation will succeed in every deployment, because ACLs, plugins and service configuration can change the result.

A successful attack can cause the directory service to treat the attacker as Directory Manager, the highest-privilege identity in the affected service. Potential consequences include:

• Reading directory data and attributes restricted to Directory Manager.
• Changing identities, groups, access controls or LDAP configuration where those actions are permitted to Directory Manager.
• Disrupting the directory service or corrupting data consumed by dependent systems.

The record does not confirm a specific disclosure, data modification or service outage. Actual organisational impact depends on the data, ACLs and systems relying on the Directory Server.

1. Prioritize the Red Hat security erratum matching the product, architecture and support branch. The advisories linked in the record are RHSA-2026:64771, RHSA-2026:64776, RHSA-2026:64778, RHSA-2026:64779, RHSA-2026:64780, RHSA-2026:64781, RHSA-2026:64783, RHSA-2026:64784, RHSA-2026:64785, RHSA-2026:64789, RHSA-2026:64790, RHSA-2026:64791, RHSA-2026:64792, RHSA-2026:64793, RHSA-2026:64804 and RHSA-2026:64811.
2. After updating, verify that the package actually running on the server is the package supplied through the matching Red Hat advisory. Do not use one upstream package version as a universal fixed boundary, because Red Hat may backport the fix.
3. If an immediate update is not possible, restrict nsslapd-allowed-sasl-mechanisms to the mechanisms actually required and remove PLAIN. Red Hat gives GSSAPI, EXTERNAL and GSS-SPNEGO as examples. This prevents the failed PLAIN bind used to plant the stale identity and blocks both the SASL ANONYMOUS variant and the low-privileged-account variant.
4. Assess compatibility before disabling PLAIN, then retest applications and integrations that depend on it. This is a mitigation and does not replace the security update.
5. If exploitation may have occurred, review LDAP changes, Directory Manager authorization, service configuration and sensitive data access from the suspected period. The record does not provide a specific recovery procedure or IOC.

Use the following checks:

1. Inventory hosts running Red Hat Directory Server or the 389-ds-base package, including deployments on Red Hat Enterprise Linux 6, 7, 8, 9 and 10 and the listed EUS, E4S, AUS, TUS or SAP branches.
2. Compare installed packages and errata state with the Red Hat advisory for the relevant product branch. Do not infer safety from an upstream package version alone, because Red Hat may backport the fix into an older distributed package.
3. If authentication telemetry records bind outcomes and connection identifiers, review connections that show a failed SASL PLAIN bind followed by a successful bind using another mechanism, especially where the resulting authority is higher than the identity just authenticated.
4. In an approved isolated test environment, verify that the identity reported after a bind matches the identity actually authenticated by that bind. Do not reproduce the authentication sequence against production.
5. If a connection appears to have received Directory Manager authority after an invalid bind, isolate the server, preserve logs and investigate LDAP operations performed through that connection. Absence of matching log evidence does not prove that the system is safe.