Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-07T15:17:31.157Z",
  "pubdate": "2026-09-07T15:17:31.157Z",
  "executiveSummary": "This vulnerability involves an authentication bypass in 389 Directory Server, specifically within the SASL PLAIN authentication workflow. The flaw allows an attacker to elevate privileges by exploiting the improper handling of stale SASL auxiliary properties across consecutive bind attempts on the same persistent connection.\nThe vulnerability is classified as an authentication bypass where the server incorrectly associates the identity from a failed authentication attempt with a subsequent, unrelated successful bind. This enables an attacker to impersonate highly privileged users, such as the 'cn=Directory Manager', without providing valid credentials.\nThe impact is critical, as it leads to full administrative unauthorized access to the directory service, allowing for data exfiltration, modification, or destruction. The attack requires the capability to initiate a persistent connection and perform multiple SASL bind operations. No prior authentication is required to initiate the attack flow, and it exploits internal state management errors within the Cyrus SASL integration of the 389 Directory Server.\nOrganizations utilizing 389 Directory Server are at high risk if they permit SASL authentication methods. Remediation necessitates applying vendor-supplied patches to clear stale auxiliary properties upon authentication state transitions.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper state management of Cyrus SASL auxiliary properties within the 389 Directory Server during the authentication lifecycle. When a SASL PLAIN bind attempt is initiated and fails, the server may cache or fail to flush the identity information associated with that specific connection attempt in the underlying Cyrus SASL layer.\nThe vulnerability manifests when a subsequent authentication request is processed on the same connection. Because the internal authentication state is not properly reset between bind attempts, the stale identity data from the previous failed attempt persists and is incorrectly applied to the new security context of the connection. This occurs regardless of the SASL mechanism used for the second, successful bind request.\nThe attack flow is executed as follows: First, the attacker establishes a connection to the 389 Directory Server. Second, the attacker issues a SASL PLAIN bind request attempting to authenticate as 'cn=Directory Manager' with a deliberately incorrect password. This step is designed to trigger the failure condition that populates the stale identity property within the server's session state.\nThird, the attacker performs a second, legitimate bind request on the same established connection. This second request can utilize any valid SASL mechanism, including SASL ANONYMOUS or a successful bind as a low-privileged account. The server, failing to clear the stale 'Directory Manager' identity property, erroneously associates this new session context with the administrative identity stored from the initial failed attempt.\nUpon the successful completion of the second bind, the server upgrades the connection's authorization level based on the stale identity data. Consequently, the server treats the connection as fully authenticated with administrative privileges. The attacker now possesses the authority of the 'cn=Directory Manager', bypassing standard authentication protocols entirely. This state persists for the duration of the connection, granting the attacker unrestricted access to all directory objects and administrative functions, effectively negating the security controls intended to protect the directory structure."
}