CVE-2026-11610: Authenticated Heap Overflow in 389 Directory Server
TL;DR - CVE-2026-11610 is a high severity heap overflow in 389-ds-base SASL I/O handling. - Authenticated users can crash vulnerable 389 Directory Server instances with a crafted SASL-protected LDAP UNBIND. - Upgrade to 389-ds-base 2.6.1 or your vendor-fixed package promptly.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-11610 |
| CVSS score | 8.8 (High) |
| Attack vector | Network, post-authentication |
| Auth required | Yes, successful SASL authentication required |
| Patch available | Yes, upstream fix available in 389-ds-base 2.6.1; Red Hat advisory RHSA-2026:26456 is published |
CVE-2026-11610 is a heap buffer overflow in the SASL I/O layer of 389 Directory Server, specifically the 389-ds-base package. Based on the NVD description, the bug is reachable only after successful SASL authentication with integrity protection enabled, which makes this a post-authentication network issue rather than an unauthenticated pre-auth flaw.
The practical risk is still serious because 389 Directory Server often sits in identity-critical paths. In FreeIPA and Red Hat Identity Management environments, valid domain users, enrolled hosts, or service accounts may be able to trigger a crash remotely after authenticating with GSSAPI. The currently confirmed impact is denial of service through server crash. Publicly available source material provided here does not confirm remote code execution.
What Is This Vulnerability?
The root cause is an improper bounds check in sasl_io_recv() within sasl_io.c. According to the NVD record, an attacker can send a specially crafted oversized LDAP UNBIND packet after completing SASL authentication with integrity protection enabled (SSF > 0). The server then copies attacker-controlled data into a fixed 512-byte heap receive buffer without verifying the payload length first.
That creates a classic heap-based buffer overflow. The description states that up to approximately 2 MB of attacker-controlled data can overflow the receive buffer, which is more than enough to corrupt process memory and crash the server. What matters operationally is that the vulnerable path is in SASL I/O processing, not in a fringe management interface. In environments where LDAP with SASL/GSSAPI is normal, the preconditions are realistic.
The issue is also notable because the vulnerable code path reportedly existed since about 2013, starting around 389-ds-base 1.3.2, and it was not addressed by the separate fix for CVE-2025-14905. That means defenders should not assume that prior memory-corruption patching in 389 Directory Server covered this path.
Technical Notes
The vulnerable condition described publicly is:
// Simplified conceptual flow based on public description
// Not vendor source code.
if (sasl_auth_success && ssf > 0) {
recv_len = get_sasl_wrapped_ldap_message();
// Missing bounds check before copy into fixed buffer
memcpy(heap_recv_buf_512, attacker_controlled_data, recv_len);
}
Attack prerequisites from public sources:
1. Successful SASL bind
2. Integrity protection enabled (SSF > 0)
3. Crafted oversized LDAP UNBIND packet
4. Trigger path in sasl_io_recv() / sasl_io.c
Who Is Affected?
The most conservative evidence-based statement is that vulnerable builds include 389-ds-base 1.3.2 and later until a fixed release is installed. The NVD description explicitly says the vulnerable code path has existed since approximately 2013 and since 389-ds-base 1.3.2. Upstream release information shows a fixed release is available as 389-ds-base 2.6.1.
Specific downstream package version strings are not fully exposed in the source material provided here, so it would be inaccurate to invent exact RHEL or IdM build numbers. What defenders should assume, in the absence of complete vendor version matrices, is that any 389 Directory Server or downstream deployment using a vulnerable 389-ds-base build and allowing SASL/GSSAPI authentication with integrity protection may be affected until the vendor-fixed package is confirmed installed.
This matters most for:
- 389 Directory Server deployments using 389-ds-base
- FreeIPA environments backed by vulnerable 389 Directory Server builds
- Red Hat Identity Management deployments with the same dependency chain
- Systems where users, service accounts, or enrolled hosts can authenticate over LDAP using GSSAPI/SASL
If you run these platforms, the attack surface is not “internet anonymous users.” It is authenticated principals that already have some level of trust in the identity fabric. That still makes the bug dangerous, because insider misuse, compromised accounts, and abused service credentials are common attack paths.
Technical Notes
Useful package inventory checks on Linux hosts:
rpm -q 389-ds-base
dnf info 389-ds-base
To identify FreeIPA or IdM systems that likely depend on the directory service:
ipactl status
systemctl status dirsrv@*
CVSS Score Breakdown
The published base score is 8.8 High. The full CVSS vector string was not exposed in the source material provided here, so defenders should avoid overstating individual metric values as if they were confirmed. Still, the score is consistent with a remotely reachable, authenticated vulnerability that can reliably crash a core service.
A high score here makes sense for several reasons. First, the issue is network-triggerable after authentication. Second, it affects availability of a central identity service, which can cascade into login failures, directory query outages, and service authentication problems across dependent systems. Third, the attack can be performed by authenticated entities that may be more common in enterprise environments than external users, such as domain accounts, hosts, and service principals.
Because the exact vector is not verified from the available record, practitioners should treat the score as authoritative but the fine-grained metrics as unknown unless confirmed directly from NVD or vendor advisories. In the absence of the vector, focus on what is known: network reachability, required authentication, and confirmed denial-of-service impact.
Technical Notes
Known severity data from the provided source set:
CVSS v3.x base score: 8.8
Severity: High
Full vector string: not verified from the provided NVD output
Confirmed impact: server crash / denial of service
Exploitation Status
At the time of writing, active exploitation in the wild is not confirmed by the provided sources. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, which means there is no KEV-based confirmation of real-world exploitation. That is helpful context, but it should not be read as proof of safety. Many denial-of-service bugs in internal identity systems are exploited opportunistically and never make it into public tracking.
Public proof-of-concept availability is also not confirmed from the source material provided here. No verified public GitHub proof of concept or public exploit reference was identified in the research note. That means defenders should currently state the exploitation picture precisely: no confirmed in-the-wild exploitation from the retrieved sources, no confirmed public PoC from the retrieved sources.
Even without a public PoC, reproduction appears straightforward enough for capable attackers who understand LDAP and SASL/GSSAPI framing. Since the crash condition is tied to an oversized SASL-protected UNBIND, organizations should prioritize patching based on asset criticality rather than waiting for exploit code to circulate.
Technical Notes
Current status summary:
CISA KEV: No
Public PoC: Not confirmed from retrieved sources
Active exploitation: Not confirmed from retrieved sources
Defender assumption: Treat as exploitable by authenticated users in exposed identity environments
How to Detect It
Detection is challenging because the trigger is an application-layer condition after successful SASL authentication. You are less likely to catch this with a simple generic IDS signature than with correlation across LDAP authentication logs, directory server crash events, and process restarts. Focus on anomalous sequences where a successful SASL/GSSAPI bind is followed immediately by connection termination, a crash, or a dirsrv process restart.
Start by reviewing 389 Directory Server logs around service interruptions. In many environments, a successful SASL bind from a user, host, or service principal shortly before a segmentation fault, abort, or unexpected daemon exit is a strong hunting lead. Because the vulnerable path involves a crafted oversized UNBIND packet, abrupt termination immediately after authenticated session setup is more suspicious than ordinary failed binds.
You should also watch for spikes in LDAP client disconnects paired with service unavailability. In IdM and FreeIPA deployments, that can surface as authentication anomalies across dependent systems rather than as one obvious application alert. If detailed packet capture is available, inspect SASL-protected LDAP sessions for unusually large post-bind traffic immediately before TCP teardown or server reset.
Technical Notes
Example process and journal hunting:
journalctl -u dirsrv@* --since "2026-07-01" | egrep -i "segfault|crash|abrt|killed|core dumped|fatal|signal"
Example system log pattern to review:
dirsrv[PID]: slapd started.
kernel: slapd[PID]: segfault at ...
systemd[1]: dirsrv@INSTANCE.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: dirsrv@INSTANCE.service: Failed with result 'core-dump'.
If directory access logs are enabled, hunt for successful SASL/GSSAPI binds preceding instability:
grep -Ei "BIND|SASL|GSSAPI|UNBIND" /var/log/dirsrv/slapd-*/access* /var/log/dirsrv/slapd-*/errors*
Example Splunk query:
index=* ("dirsrv" OR "slapd")
("SASL" OR "GSSAPI" OR "BIND")
| transaction host maxspan=2m
| search ("segfault" OR "core dumped" OR "Main process exited" OR "Failed with result")
Network-oriented heuristic for SOC teams:
Look for LDAP sessions over SASL/GSSAPI where a successful authenticated exchange is followed by
an unusually large wrapped payload and immediate server-side connection reset or daemon restart.
Mitigation and Patching
The primary mitigation is to upgrade to a fixed package. Based on the provided evidence, the upstream fixed release is 389-ds-base 2.6.1. Red Hat has also published RHSA-2026:26456, indicating that vendor packages are available for at least some supported Red Hat offerings. If you are on a downstream distribution, use the vendor advisory to determine the exact fixed package for your channel rather than relying solely on upstream version numbers.
If immediate patching is not possible, reduce exposure by limiting who can authenticate using SASL/GSSAPI to the affected service, especially broad user populations that do not need direct LDAP access. Because exploitation requires successful SASL authentication with integrity protection enabled, tighter ACLs, service segmentation, and strict control of service accounts and host principals can reduce practical risk. These are compensating controls, not substitutes for patching.
Another useful temporary measure is to restrict network reachability to the directory service from only approved application hosts and administrative jump points. In environments where LDAP access is unnecessarily broad, network segmentation can materially reduce the chance that a compromised workstation account or misused service credential can reach the vulnerable target.
Technical Notes
Check the currently installed version:
rpm -q 389-ds-base
Upgrade on DNF-based systems, using the vendor-provided update channel:
sudo dnf upgrade 389-ds-base
If you specifically need to install the upstream fixed version where available in your repository set:
sudo dnf install 389-ds-base-2.6.1
Restart and verify service state after patching:
sudo systemctl restart dirsrv@INSTANCE
sudo systemctl status dirsrv@INSTANCE
Temporary access-reduction steps may include firewalling LDAP/LDAPS to approved sources only. Example with firewalld rich rules:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.10.0/24" port protocol="tcp" port="389" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.10.0/24" port protocol="tcp" port="636" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port protocol="tcp" port="389" drop'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port protocol="tcp" port="636" drop'
sudo firewall-cmd --reload
If you cannot confirm your exact fixed package version from vendor documentation immediately, assume vulnerable until:
1. you verify the advisory that applies to your platform, and
2. you confirm the updated package is installed.
References
The following sources support the core facts in this article. The NVD entry provides the most complete public technical description in the source set, including trigger conditions, root cause location, and confirmed impact. The upstream release page confirms that 389-ds-base 2.6.1 exists as a released version. The Red Hat advisory indicates vendor security updates are available, though defenders should consult the full advisory for exact package applicability in their environment.
- NVD CVE record for CVE-2026-11610: https://nvd.nist.gov/vuln/detail/CVE-2026-11610
- CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Red Hat CVE page: https://access.redhat.com/security/cve/CVE-2026-11610
- Red Hat Bugzilla 2484414: https://bugzilla.redhat.com/show_bug.cgi?id=2484414
- Red Hat advisory RHSA-2026:26456: https://access.redhat.com/errata/RHSA-2026:26456
- 389 Directory Server 2.6.1 release notes: https://www.port389.org/docs/389ds/releases/release-2-6-1.html
Technical Notes
Suggested validation checklist after remediation:
- Confirm advisory applicability for your OS and support channel
- Confirm installed 389-ds-base package version
- Restart affected dirsrv instances if required by your change process
- Review logs for crash recurrence after patch window
- Limit LDAP exposure until patch verification is complete
For further reading, you can also explore related topics on incident response and digital forensics.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.