CVE-2026-11770: 389 Directory Server Info Disclosure Flaw

CVE-2026-11770 Overview

CVE-2026-11770 is an LDAP injection vulnerability in the 389 Directory Server. An unauthenticated remote attacker can inject LDAP search filters into the CleanAllRUV replication status-check extended operation. The handler executes the crafted search against cn=config using elevated replication plugin privileges. Because the operation returns a boolean match result, attackers can perform blind LDAP filter oracle attacks to extract sensitive configuration data. Exposed information includes replication bind Distinguished Names (DNs) and password storage scheme details, which support follow-on attacks against the directory. The flaw is tracked under CWE-90 (Improper Neutralization of Special Elements used in an LDAP Query).

Critical Impact
Unauthenticated remote attackers can exfiltrate replication bind DNs, password hash scheme metadata, and other cn=config values from an exposed 389 Directory Server.

Affected Products

389 Directory Server (389-ds-base) upstream project
Red Hat Directory Server distributions incorporating the vulnerable repl_extop.c handler
Downstream Linux distributions packaging affected 389-ds-base releases

Discovery Timeline

2026-07-31 - CVE-2026-11770 published to the National Vulnerability Database (NVD)
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-11770

Vulnerability Analysis

The 389 Directory Server implements a CleanAllRUV extended operation used to remove replica update vector (RUV) entries from replication metadata. A status-check subroutine within this operation accepts attacker-controlled input and incorporates it into an LDAP search filter without proper neutralization. The search is then dispatched internally against the cn=config subtree, which stores server configuration such as replication agreements, bind identities, and password storage schemes.

Because the internal search runs with the replication plugin's elevated privileges, standard access controls that would normally restrict anonymous clients from reading cn=config do not apply. The extended operation returns a boolean response indicating whether the search matched. An attacker can iterate injected filter clauses to reveal configuration values one bit at a time, producing a blind LDAP injection oracle.

Root Cause

The root cause is missing input sanitization in the CleanAllRUV status-check handler in ldap/servers/plugins/replication/repl_extop.c. Attacker-supplied bytes are concatenated into an LDAP filter string rather than escaped per RFC 4515. The privileged execution context of the replication plugin amplifies the exposure by bypassing normal access control instructions (ACIs) on cn=config.

Attack Vector

Exploitation requires only network access to the LDAP or LDAPS port and no authentication. The attacker sends a crafted LDAP extended operation request that embeds arbitrary filter fragments into the status-check parameter. By observing the boolean response, the attacker performs a character-by-character extraction of target attributes such as nsds5ReplicaBindDN, nsds5ReplicaCredentials metadata, and passwordStorageScheme. See the 389-ds-base source reference for the affected handler and the Red Hat CVE-2026-11770 advisory for vendor details.

Detection Methods for CVE-2026-11770

Indicators of Compromise

Unauthenticated LDAP extended operation requests targeting the CleanAllRUV OID from external or unexpected internal sources.
Repeated CleanAllRUV status-check requests from a single client with varying payload parameters, consistent with blind extraction.
Access log entries showing anonymous binds followed immediately by extended operation calls referencing replication tasks.

Detection Strategies

Enable verbose 389 Directory Server access and error logging, then alert on extended operation OIDs invoked without an authenticated bind.
Inspect network traffic for LDAP ExtendedRequest PDUs containing filter metacharacters such as *, (, ), or \ in CleanAllRUV parameters.
Correlate directory audit events against threat intelligence for known LDAP injection tooling and payload patterns.

Monitoring Recommendations

Forward access, errors, and audit logs from /var/log/dirsrv/slapd-<instance>/ into a centralized logging or SIEM platform for retention and correlation.
Baseline the expected volume of replication extended operations and alert on deviations, especially from non-replica peers.
Monitor for anonymous read attempts against cn=config and for spikes in extended operation error responses.

How to Mitigate CVE-2026-11770

Immediate Actions Required

Apply the vendor-provided 389-ds-base update as soon as fixed packages are available from your Linux distribution or Red Hat.
Restrict LDAP and LDAPS network exposure to trusted replica peers and administrative subnets using host or network firewalls.
Rotate replication bind account credentials after patching, since replication bind DN metadata may already be exposed.
Review cn=config for any secrets, scheme identifiers, or agreement details that should be treated as compromised.

Patch Information

Refer to the Red Hat CVE-2026-11770 advisory and Red Hat Bugzilla #2484802 for fixed package versions and errata. Upstream fixes will be published against the 389-ds-base project referenced in the GitHub code tree. Apply updates on all directory replicas and hubs in the topology.

Workarounds

Block or firewall the LDAP extended operation endpoint from untrusted networks until patched packages are deployed.
Disable or restrict the replication plugin on instances that do not participate in multi-supplier replication.
Place the directory server behind an LDAP-aware proxy that rejects CleanAllRUV extended operations from unauthenticated clients.

bash

# Example: restrict LDAP/LDAPS access to trusted replica peers with firewalld
sudo firewall-cmd --permanent --new-zone=ldap-replicas
sudo firewall-cmd --permanent --zone=ldap-replicas --add-source=10.0.10.0/24
sudo firewall-cmd --permanent --zone=ldap-replicas --add-port=389/tcp
sudo firewall-cmd --permanent --zone=ldap-replicas --add-port=636/tcp
sudo firewall-cmd --permanent --zone=public --remove-service=ldap
sudo firewall-cmd --permanent --zone=public --remove-service=ldaps
sudo firewall-cmd --reload