Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-01T22:17:05.590Z",
  "pubdate": "2026-10-01T22:17:05.590Z",
  "executiveSummary": "A vulnerability in 389-ds-base allows an unauthenticated remote attacker to cause a Denial of Service (DoS) by exhausting the server's worker thread pool.\nThe issue stems from improper handling of fragmented LDAPMessage sequences on a single connection, which leads to internal synchronization conflicts.\nBy manipulating connection states to force worker threads to wait on a connection mutex while hitting the nsslapd-ioblocktimeout, an attacker can effectively lock the entire thread pool.\nThis impacts all services provided by the directory server, including both anonymous and authenticated operations across plaintext and TLS-encrypted channels.\nThe exploit requires minimal resources, as the number of connections needed to block the server is directly proportional to the configured worker-thread pool size, making it a highly efficient resource exhaustion attack.",
  "technicalDetails": "The vulnerability resides in the connection handling architecture of 389-ds-base. The server employs a multi-threaded worker pool to process LDAP operations. The flaw is triggered when a client submits a complete, valid LDAP operation followed immediately by the initial bytes of an incomplete LDAPMessage on the same connection socket.\nUnder normal circumstances, the server should process the initial operation and flush the results back to the client. However, the current implementation allows the connection to be handed over to a second worker thread before the first thread has completed the flush process for the initial operation.\nBecause the connection mutex is still held or required during this state transition, the second worker thread enters a blocked state. This thread waits until the duration defined by nsslapd-ioblocktimeout expires. During this timeout period, the connection mutex remains locked, preventing other threads from accessing or clearing the state of that connection.\nThe attack flow follows a deterministic pattern: 1) The attacker initiates an LDAP connection; 2) The attacker sends a full, valid request; 3) The attacker sends partial bytes of a subsequent message; 4) The server dispatches a second thread to handle the incoming bytes; 5) The server's locking mechanism stalls both threads due to the mutex contention; 6) The worker thread pool becomes depleted as the attacker repeats this process for each available worker thread.\nOnce the number of exhausted threads matches the defined worker pool capacity, the directory server ceases to process any further incoming requests. This results in a complete suspension of service availability for all legitimate clients, regardless of their authentication state or transport security configuration. The deadlock persists as long as the attacker maintains the blocked connections, effectively rendering the service unavailable until the malicious sessions are forcibly terminated or the service is restarted.\nThis vulnerability is particularly critical as it does not require prior authentication or elevated privileges. It leverages standard LDAP protocol behaviors to manipulate internal synchronization primitives within the 389-ds-base daemon, bypassing standard request-level processing limits."
}