389-ds-base Critical Flaws: Heap Overflow and Auth Bypass Hit RHEL and AlmaLinux Directory Server
Red Hat shipped a Critical-rated update for 389-ds-base (the package behind Red Hat Directory Server, and the upstream for AlmaLinux and other RHEL-compatible distributions’ directory services) covering four real vulnerabilities, with a combined severity that includes a CVSS 9.8. If you’re running 389-ds-base, Red Hat Directory Server, or FreeIPA (which uses 389-ds-base as its LDAP backend) on RHEL, AlmaLinux, Rocky, or similar, this is worth checking today, not next maintenance window.
This server doesn’t run 389-ds-base (it’s a standard Ubuntu web host, not a directory server), so the commands below are accurate, standard package-management checks for your own 389-ds-base/Directory Server install, not lab-captured output from our own infrastructure.
The four vulnerabilities, and why the combination matters
- CVE-2026-18355, a heap buffer overflow via an integer underflow in SASL wrapped-record length handling (
sasl_io_start_packet()), triggerable from crafted SASL traffic. - CVE-2026-18453, a pre-authentication NULL pointer dereference via paged results combined with the USE_ONE_BACKEND control in shared search operations, a denial-of-service path that needs no valid credentials at all.
- CVE-2026-18922, privilege escalation to Directory Manager (the equivalent of root for the directory) via a stale identity left behind in a Cyrus SASL auxiliary property during PLAIN authentication.
- CVE-2026-76560, an anonymous LDAP client bypassing SELFDN ACI bind-rule checks via an empty bind DN, letting an unauthenticated client defeat access controls that were supposed to require the bind identity to match the target entry.
Individually, each is serious. Together, they describe a realistic chain: an unauthenticated or lightly-authenticated client can crash the service (CVE-2026-18453), bypass access controls meant to restrict what anonymous binds can see or do (CVE-2026-76560), and under the right conditions escalate all the way to Directory Manager (CVE-2026-18922), the account that can read, modify, or delete anything in the directory. A directory server compromise at that level is comparable in severity to a domain controller compromise on the Active Directory side, since 389-ds-base/Directory Server and FreeIPA are frequently the authoritative identity source for Linux environments.
Step 1: check your current 389-ds-base version
# RHEL / AlmaLinux / Rocky (dnf-based)
rpm -q 389-ds-base
dnf list installed 389-ds-base
# If you're running FreeIPA, it depends on 389-ds-base, check both
rpm -q freeipa-server 389-ds-baseCompare the returned version/release against the fixed versions in your distribution’s advisory, RHSA-2026:64793 (RHEL 8), the corresponding RHEL 9/10 advisories, or ALSA-2026:64784 for AlmaLinux. The exact fixed version differs by major release and update stream, check your specific advisory rather than assuming a single version number applies across RHEL 8, 9, and 10.
Step 2: apply the update
# RHEL / AlmaLinux / Rocky
sudo dnf update 389-ds-base
sudo systemctl restart dirsrv@<instance-name>
# Confirm the service came back up cleanly
sudo systemctl status dirsrv@<instance-name>
sudo dsconf -D "cn=Directory Manager" ldap://localhost statusIf you’re running FreeIPA, update through dnf update as normal, FreeIPA’s own packaging pulls in the corrected 389-ds-base dependency, you don’t need to update the directory server component separately from the rest of the FreeIPA stack.
Step 3: review for anonymous bind abuse
Since CVE-2026-76560 specifically concerns anonymous LDAP clients bypassing access controls, review your directory’s access log for unusual anonymous bind activity before you patch, particularly reads or searches against entries that a legitimate anonymous bind shouldn’t be able to see under your configured ACIs.
# 389-ds-base access log, typically here, adjust instance name
sudo grep "BIND dn=\"\"" /var/log/dirsrv/slapd-<instance-name>/access | tail -50An empty bind DN (dn="") is the anonymous bind signature to look for, followed by what that session searched for or accessed afterward.
Quick guide
- Check your installed 389-ds-base version with
rpm -q 389-ds-base. - Compare it against your distribution’s specific advisory (RHSA or ALSA) for your RHEL major version.
- Apply the update and restart the
dirsrvinstance. - Confirm the service is healthy afterward with
dsconf ... status. - Grep your access log for anonymous binds (
dn="") and review what they accessed before the patch went in.
FAQ
Does this affect plain OpenLDAP installs too?
No, these CVEs are specific to the 389-ds-base codebase (used by Red Hat Directory Server and its 389 Directory Server upstream project). OpenLDAP is a separate, unrelated codebase and isn’t affected by these specific vulnerabilities.
Do I need to do anything extra if I run FreeIPA?
A standard dnf update pulls in the corrected 389-ds-base version as a FreeIPA dependency. You don’t need a separate manual step for the directory server component, just make sure your regular FreeIPA update actually ran and completed on every IPA server in your topology, not just the first one.
What does CVSS 9.8 actually mean here versus the individual CVE scores?
The 9.8 figure corresponds to the most severe of the four CVEs in this update individually, reflecting low attack complexity and no privileges or user interaction required for that specific flaw. The other three CVEs in the same update carry their own, somewhat lower individual scores, but patching the single package update addresses all four together.
Is a service restart enough, or do I need to reboot the whole server?
Restarting the specific dirsrv@<instance> service is sufficient to load the patched binaries for that directory instance, a full server reboot isn’t required for this update specifically, though you should still follow your normal patch management process for any other packages updated in the same maintenance window.
