CVE-2026-11793: 389 Directory Server Buffer Overflow Flaw

CVE-2026-11793 Overview

CVE-2026-11793 is a stack buffer overflow vulnerability in the 389 Directory Server, an enterprise Lightweight Directory Access Protocol (LDAP) server maintained by Red Hat. The flaw resides in the checkPrefix() function within pw.c, which handles parsing of reversible-encrypted attribute values. The function copies an attacker-controlled algorithm identifier into a 256-byte stack buffer without performing bounds checking. An authenticated attacker holding Directory Manager privileges can store a crafted credential with an oversized algorithm ID and crash the LDAP service. Compiler-level FORTIFY_SOURCE protections constrain the impact to denial of service rather than arbitrary code execution.

Critical Impact
Authenticated attackers with Directory Manager privileges can trigger a stack buffer overflow that terminates the LDAP server process, resulting in denial of service for directory-dependent applications.

Affected Products

389 Directory Server (upstream project)
Red Hat Directory Server distributions including the vulnerable checkPrefix() implementation
Downstream LDAP deployments built on the 389-ds-base codebase

Discovery Timeline

2026-06-09 - CVE-2026-11793 published to NVD
2026-06-09 - Last updated in NVD database

Technical Details for CVE-2026-11793

Vulnerability Analysis

The vulnerability is classified under [CWE-121] Stack-based Buffer Overflow. The defect lives in the checkPrefix() routine inside pw.c, the password handling source file in 389 Directory Server. The function parses reversible-encrypted attribute values that follow a {algorithm}ciphertext syntax, similar to RFC 3112 authentication password schemes. When checkPrefix() extracts the algorithm identifier between the curly braces, it copies the value into a fixed 256-byte stack buffer using an unbounded copy operation.

Because no length validation occurs before the copy, an algorithm prefix longer than 256 bytes overruns the stack frame. The overflow corrupts saved return addresses, frame pointers, and adjacent local variables. Glibc FORTIFY_SOURCE instrumentation detects the corruption at runtime and aborts the process, downgrading the outcome from arbitrary code execution to a controlled crash.

Root Cause

The root cause is missing input validation on attacker-controlled string length before a stack buffer copy. The checkPrefix() implementation trusts the algorithm identifier extracted from stored credential data and uses an unbounded string copy primitive rather than a length-limited variant such as strncpy or snprintf with explicit size constraints.

Attack Vector

Exploitation requires Directory Manager privileges, the highest administrative role in a 389 Directory Server deployment. The attacker authenticates over the network using LDAP, then writes a crafted reversible-encrypted credential to a target entry. The malicious value contains an algorithm ID exceeding 256 bytes. When the server subsequently parses the stored credential through checkPrefix(), the overflow triggers and FORTIFY_SOURCE aborts the ns-slapd process. The result is loss of LDAP availability for all dependent clients.

No public proof-of-concept exploit code is available. See the Red Hat Bug Report for additional technical context.

Detection Methods for CVE-2026-11793

Indicators of Compromise

Unexpected termination or repeated restarts of the ns-slapd daemon process on directory servers
Glibc *** stack smashing detected *** messages or SIGABRT entries in system logs and core dumps tied to ns-slapd
LDAP modify operations from Directory Manager accounts writing unusually large values to password or reversible-encrypted attributes
Sudden loss of LDAP bind availability for downstream applications following a directory write event

Detection Strategies

Audit 389 Directory Server access logs for MOD operations targeting password attributes with payload sizes exceeding several hundred bytes
Correlate ns-slapd process crashes with preceding authenticated LDAP write operations from privileged accounts
Monitor for abuse of Directory Manager credentials, including authentication from unexpected source addresses or service accounts

Monitoring Recommendations

Forward 389 Directory Server access, audit, and error logs to a centralized logging platform for retention and correlation
Enable systemd or process supervisor restart counters and alert when ns-slapd exceeds a baseline crash threshold
Track privileged role usage with dedicated alerts on Directory Manager bind events outside maintenance windows

How to Mitigate CVE-2026-11793

Immediate Actions Required

Restrict Directory Manager credentials to a minimal set of administrators and store them in a privileged access management system
Rotate any Directory Manager passwords that may have been exposed to non-administrative personnel
Disable or restrict reversible password storage schemes where not required by application integrations
Apply vendor security updates as soon as fixed packages are published by your distribution

Patch Information

Red Hat is tracking the issue through its security response process. Refer to the Red Hat CVE Advisory and Red Hat PSIRT Tracking for current package availability and errata identifiers. Apply the updated 389-ds-base package once your distribution publishes the fix and restart the dirsrv service to load the patched binaries.

Workarounds

Limit network exposure of the LDAP service to trusted management subnets using host firewalls or network segmentation
Audit and remove unnecessary accounts that hold Directory Manager privileges
Configure LDAP access control instructions (ACIs) to constrain who can modify password attributes on sensitive entries
Enable automatic service restart for ns-slapd to reduce outage duration if the crash is triggered

bash

# Restrict ns-slapd restart behavior and tighten Directory Manager exposure
sudo systemctl edit dirsrv@<instance>.service
# Add the following override to limit downtime if a crash occurs:
# [Service]
# Restart=on-failure
# RestartSec=5s

# Limit LDAP/LDAPS to management network only
sudo firewall-cmd --permanent --zone=public --remove-service=ldap
sudo firewall-cmd --permanent --zone=public --remove-service=ldaps
sudo firewall-cmd --permanent --zone=internal --add-service=ldaps
sudo firewall-cmd --reload