CVE-2026-86344 in Directory Server
Summary
by MITRE • 10/02/2026
A flaw was found in 389-ds-base. An unauthenticated remote attacker can send a complete LDAP operation followed by the first bytes of an incomplete LDAPMessage on the same connection, causing the server to hand that connection to a second worker thread before the first worker's result is flushed. The second worker blocks until nsslapd-ioblocktimeout while holding the connection mutex, preventing delivery of the completed operation's result. Repeating this across a small number of connections proportional to the configured worker-thread pool size exhausts the entire pool under default configuration, denying service to all clients (anonymous and authenticated, plaintext and TLS) for as long as the attacker maintains the connections.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in 389-ds-base represents a critical denial of service flaw rooted in improper synchronization mechanisms within the LDAP server's connection handling logic. This issue allows an unauthenticated remote attacker to exploit race conditions and blocking behaviors inherent in the multi-threaded architecture of the directory server. By sending a complete Lightweight Directory Access Protocol operation followed immediately by the initial bytes of an incomplete LDAPMessage on the same TCP connection, the attacker triggers a specific sequence of events that disrupts normal thread management. The core technical flaw lies in how the server assigns connections to worker threads and manages mutex locks during asynchronous operations. When such a malformed request is received, the server prematurely hands off the connection handle to a second available worker thread before the first worker has finished flushing its response for the completed operation. This architectural misstep creates a deadlock scenario where resource contention prevents proper service delivery.
The operational mechanics of this exploit rely on the interaction between the I/O blocking timeout and mutex locking strategies. Once the second worker thread takes over the connection, it enters a blocked state waiting for data that will never arrive due to the incomplete nature of the subsequent LDAPMessage fragment. Crucially, while in this blocked state, the second worker retains possession of the connection mutex. This lock is essential for managing access to shared resources associated with the client session. Because the thread remains stuck waiting on an input/output block timeout defined by the nsslapd-ioblocktimeout configuration parameter, it holds onto these critical locks indefinitely or until a very long timeout expires. During this period, any other operations attempting to use that connection or related server resources are forced to wait, effectively stalling progress for legitimate users associated with that session context.
The impact of this vulnerability is severe and results in a complete denial of service against the directory infrastructure. By repeating this attack pattern across a number of connections proportional to the configured worker-thread pool size, an attacker can exhaust all available server threads. Under default configurations, which typically allocate a limited set of workers for handling concurrent requests, filling every thread with these blocked, mutex-holding sessions leaves no resources free to process legitimate traffic. Consequently, both anonymous and authenticated clients are denied service regardless of whether they connect via plaintext or TLS encrypted channels. The denial persists as long as the attacker maintains these malicious connections, effectively rendering the 389-ds-base instance unusable for any administrative tasks, authentication requests, or directory queries until the threads eventually time out or the server is restarted.
From a classification perspective, this vulnerability aligns with CWE-400 Uncontrolled Resource Consumption and CWE-772 Missing Release of Resource after Effective Lifetime due to improper synchronization leading to resource exhaustion. The attack vector leverages timing dependencies that can be categorized under ATT&CK technique T1499 Endpoint Denial of Service, specifically involving resource exhaustion through application layer flooding or logic exploitation rather than simple volumetric network flooding. This distinction is important for defenders as it highlights the need for deep packet inspection and stateful analysis rather than just bandwidth monitoring to detect such attacks. The ability to exploit this from an unauthenticated position further elevates the severity, allowing any external actor with network access to disrupt critical identity management services without needing valid credentials.
Mitigation strategies must address both immediate remediation and long-term architectural resilience. The primary defense is applying vendor-provided patches that update 389-ds-base to a version where this race condition has been resolved through improved mutex handling or connection state validation. Administrators should ensure their directory servers are updated promptly upon the release of security advisories addressing this specific flaw. In environments where immediate patching is not feasible, network-level controls can provide temporary relief. Implementing rate limiting on LDAP connections and enforcing stricter timeouts for incomplete messages can reduce the window of opportunity for attackers to exhaust thread pools. Additionally, increasing the worker-thread pool size may delay the onset of total service denial but does not eliminate the underlying vulnerability; it merely increases the scale required to achieve a successful attack. Long-term architectural reviews should consider implementing connection multiplexing or asynchronous I/O models that decouple request processing from strict mutex dependencies on individual connections, thereby preventing single malformed requests from blocking broader server resources.