CVE-2026-18922: 389-ds-base: 389-ds-base: sasl plain authentication allows privilege escalation to directory manager via stale identity in cyrus sasl auxiliary property
A flaw was found in 389 Directory Server (389-ds-base). During SASL PLAIN authentication, the idssaslcanonuser() function writes the resolved bind DN into a Cyrus SASL auxiliary property (propset) on every canonicalization attempt, including failed ones. A failed one-shot PLAIN exchange does not trigger SASL-context recreation in idssaslcheckbind() -- that only happens when CONNFLAGSASLCOMPLETE or continuing is already set. A subsequent successful SASL bind on the same connection retrieves the auxiliary property via propgetnames() and unconditionally trusts only the first stored value (dnval[0].values[0]), with no check on which SASL mechanism completed the second exchange and no check that the value corresponds to the identity actually just authenticated.
An unprivileged remote attacker can exploit this with zero valid credentials: first send a SASL PLAIN bind as cn=Directory Manager with an incorrect password (fails as expected, but leaves the Directory Manager DN in slot 0 of the auxiliary property), then complete a SASL ANONYMOUS bind on the same connection. The server installs the stale Directory Manager identity instead of the anonymous identity, granting full Directory Manager authority. This was independently confirmed by Red Hat Product Security in an isolated, network-disconnected sandbox against 389-ds-base-2.9.0: "Who Am I?" returned "cn=directory manager", and the Directory-Manager-only cn=config attribute nsslapd-rootdn became readable. The same stale-identity mechanism also allows escalation via a valid low-privileged account's own successful second bind (originally reported variant, requiring one valid account), independently reproduced against the reporter's own PoC.
Root cause: ldap/servers/slapd/saslbind.c, idssaslcanonuser() (identity write, unconditional per mechanism) and idssaslcheckbind() (identity read-back and installation, no mechanism check, no freshness check). Verified directly against commit 33c0e0115c03017ba94ee02f144383704de32a25; unchanged since a September 2024 logging-format cleanup.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
389-ds-baseto a version that resolves this vulnerability.Fixed in 2.9.0Patch commit 33c0e0115c03017ba94ee02f144383704de32a25 - Compensating control
Apply network-side access controls to the directory server so only trusted hosts can reach the SASL bind endpoints, reducing exposure to unauthenticated remote exploitation (described as “unprivileged remote attacker” with “zero valid credentials”).
- Operational
After patching, validate SASL bind behavior for the reported scenario (failed SASL PLAIN then successful SASL ANONYMOUS on same connection) and confirm that privilege escalation is not possible (e.g., “Who Am I?” should not return “cn=directory manager”).
Event History
Frequently Asked Questions
Does exploitation require valid directory credentials or prior access?
No. An unprivileged remote attacker can exploit the issue with zero valid credentials by submitting a failed SASL PLAIN bind using the Directory Manager DN and an incorrect password.
What sequence is required to obtain elevated access?
The attacker must keep the same connection after the failed PLAIN exchange, then complete a SASL ANONYMOUS bind. The server can reuse the stale Directory Manager DN stored during the failed attempt rather than the identity authenticated by the later exchange.
What level of access can successful exploitation grant?
Successful exploitation installs the stale Directory Manager identity for the connection, granting full Directory Manager privileges.