CVE-2026-18663: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-18663 is a pre-authentication double-free vulnerability in 389-ds-base (Red Hat Directory Server) affecting the get_ldapmessage_controls_ext() function. When a BIND request carries a critical Session Tracking control (OID 1.3.6.1.4.1.21008.108.63.1), the function frees the parsed controls array on the rejection path without clearing the SLAPI_REQCONTROLS pblock slot, causing operation teardown to free the same pointer again. Only 389-ds-base 3.x versions are affected (RHEL 10, RHDS 13, Fedora); versions 2.x and 1.4.x lack the Session Tracking feature and are not affected. The vulnerability was reported on August 3, 2026 and publicly disclosed on August 12, 2026, with a CVSS v3.1 base score of 5.9 (Medium) (Red Hat CVE, Github Advisory).

The root cause is a double-free memory error (CWE-415) introduced in commit fd627001b (Issue 6367, merged 2024-11-29) which added Session Tracking control support to 389-ds-base. During LDAP control parsing, get_ldapmessage_controls_ext() publishes the decoded controls array into the operation's pblock (SLAPI_REQCONTROLS), then — if the Session Tracking control is marked critical — rejects the request via an error path that calls ldap_controls_free() without nullifying the pblock slot. Subsequently, operation_done() frees the same pointer again through o_params.request_controls, producing heap corruption. Because controls are parsed before authentication, an unauthenticated attacker can trigger this with a single malformed BIND request over the network (port 389/636). On RHEL product builds linked against jemalloc, the double-free is silently absorbed; however, on upstream/Fedora builds using the glibc allocator, the server reliably crashes (Red Hat CVE, Red Hat Bugzilla).

Successful exploitation results in heap corruption and potential denial of service by crashing the ns-slapd process. On RHEL 10 and RHDS 13 builds (using jemalloc), the server continues running despite the double-free, limiting the practical impact; however, on upstream and Fedora builds using the glibc allocator, the server reliably crashes, causing a full denial of service for all LDAP-dependent services. No information disclosure or privilege escalation has been demonstrated, and the confidentiality and integrity impacts are rated None (Red Hat CVE, Red Hat Bugzilla).

No public exploit code or in-the-wild exploitation has been reported as of the disclosure date. The NVD SSVC assessment indicates exploitation is "none" and the attack is not automatable due to high attack complexity. The EPSS score is approximately 0.397% (33rd percentile), reflecting a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory, Red Hat CVE).

1. Reconnaissance: Identify internet-facing or network-accessible LDAP servers running 389-ds-base 3.x (RHEL 10, RHDS 13, or Fedora) on port 389 (LDAP) or 636 (LDAPS) using tools like Shodan, Censys, or nmap.
2. Craft malicious BIND request: Construct an LDAP BIND request that includes the Session Tracking control (OID 1.3.6.1.4.1.21008.108.63.1) with the criticality flag set to TRUE. This can be done using Python's ldap3 library or raw LDAP BER encoding tools.
3. Send the request: Transmit the crafted BIND request to the target server. No authentication credentials are required — the vulnerability is triggered during control parsing, before authentication occurs.
4. Trigger double-free: The server's get_ldapmessage_controls_ext() function rejects the critical Session Tracking control, frees the controls array, but leaves the SLAPI_REQCONTROLS pblock slot populated. Operation teardown then frees the same pointer again.
5. Achieve denial of service: On glibc-based builds (upstream/Fedora), the double-free causes ns-slapd to crash, denying LDAP service to all clients. On jemalloc-based builds (RHEL/RHDS), the crash may not occur but heap corruption is still induced (Red Hat CVE, Red Hat Bugzilla).

• Network: Unexpected or repeated unauthenticated BIND requests to LDAP port 389 or 636 from external or untrusted IP addresses; LDAP packets containing the Session Tracking control OID (1.3.6.1.4.1.21008.108.63.1) with criticality set to TRUE.
• Logs: 389-ds access logs (/var/log/dirsrv/slapd-*/access) showing BIND operations that immediately result in an error response (e.g., err=12 unavailable critical extension) followed by connection termination; repeated such patterns from the same source IP.
• Process: Unexpected termination or restart of the ns-slapd process; core dump files generated in the 389-ds working directory (on glibc builds); ASan or heap corruption error messages in the errors log (/var/log/dirsrv/slapd-*/errors).
• File System: Core dump files (e.g., core.*) in /var/log/dirsrv/ or the ns-slapd working directory following a crash (Red Hat CVE, Red Hat Bugzilla).

On builds that include upstream Issue 7389 (committed 2026-04-09, present in the 389-ds-base-3.2 branch), administrators can add the Session Tracking control OID (1.3.6.1.4.1.21008.108.63.1) to the ds-ignored-control-criticality configuration attribute, which prevents the server from entering the vulnerable rejection path. Additionally, restricting network-level access to LDAP ports (389/636) to trusted clients only reduces exposure. Upgrading to a patched version of 389-ds-base-3.x (once available) is the recommended long-term remediation; RHEL 10 and RHDS 13 users should monitor Red Hat errata for official package updates (Red Hat CVE, Red Hat Bugzilla).

Red Hat rates this issue as Moderate severity (rather than High), noting that on RHEL 10 and RHDS 13 product builds, the jemalloc allocator absorbs the double-free without crashing, and live testing confirmed the server continues running. The vulnerability was credited to Adam Korczynski, Arthur Chan, and David Korczynski (Ada Logics), as well as a team from Anthropic, indicating it was discovered through security research and fuzzing efforts. The GitHub Advisory Database classifies it as Moderate severity, consistent with Red Hat's assessment (Red Hat CVE, Github Advisory).