CVE-2026-18922 needs no account and no unusual configuration, and Red Hat’s own product data lists 31 affected products, one unaffected, and zero with a fix.
What happened
Red Hat published CVE-2026-18922 to the National Vulnerability Database on September 7, 2026, at 3:17 p.m. UTC. The record is in NVD’s Received state, carries a single CVSS score from the assigning CNA [email protected] — 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — and is classified CWE-287, improper authentication.
The description is unusually specific about how to do it:
A flaw was found in 389 Directory Server. During SASL PLAIN authentication, a stale identity carried in a Cyrus SASL auxiliary property from a prior failed bind attempt can be installed on a connection following a subsequent, unrelated successful bind, regardless of which SASL mechanism completes that second bind. An attacker can send a SASL PLAIN bind as cn=Directory Manager with an incorrect password, then complete a SASL ANONYMOUS bind on the same connection, causing the server to grant Directory Manager authority without any valid credentials. A variant using a valid low-privileged account’s own successful bind instead of an anonymous one is also possible.
Red Hat’s CSAF VEX document, released at 2:47 p.m. UTC the same day, is titled “389-ds-base: SASL PLAIN authentication allows privilege escalation to Directory Manager via stale identity in Cyrus SASL auxiliary property.” Its statement:
This flaw is rated Critical because it allows a remote, unauthenticated attacker to gain full Directory Manager privileges over an LDAPS connection — with no valid account, no user interaction, and no non-default configuration required.
The remediation Red Hat offers is a configuration change, not a package:
Administrators can restrict nsslapd-allowed-sasl-mechanisms to only the mechanisms actually required (e.g. GSSAPI, EXTERNAL, GSS-SPNEGO), excluding PLAIN.
The VEX product status lists 31 products under known_affected — Red Hat Directory Server 11 and 12, and the 389-ds-base packages across Red Hat Enterprise Linux 6, 7, 8, 9, and 10. One product sits under known_not_affected: Red Hat Directory Server 13. Nothing is listed as fixed.
Four more in the same batch
CVE-2026-18922 arrived with four other 389 Directory Server records published by Red Hat on September 7, none of which has a fix either:
- CVE-2026-19843, 8.4,
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H— command injection through an unescaped LDAP distinguished name in the Cockpit 389 Console LDAP editor. Thirty products affected, eight not affected, zero fixed. Deployments without the Cockpit console are not affected. - CVE-2026-18355, 7.5,
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H— a heap buffer overflow insasl_io_start_packet(), where the wrapped-record length read from the wire is validated only against an upper bound. Twenty-nine affected, four not affected, zero fixed. Red Hat’s workaround field reads: “Red Hat has investigated whether a possible mitigation exists for this issue, and has not been able to identify a practical example.” - CVE-2026-18453, 7.5 — a missing NULL pointer check in paged-results handling that lets an unauthenticated remote attacker crash
ns-slapd. - CVE-2026-76560, 7.5 — the SELFDN ACI bind-rule evaluator matching an anonymous client’s empty bind DN against an empty stored attribute value. This is the directory-server half of the unauthenticated FreeIPA administrator chain published the same day, covered separately.
Red Hat Directory Server 13 is listed as not affected by CVE-2026-18922, CVE-2026-18355 and CVE-2026-76560. It is the only product that appears on the clean side of all three.
Why it matters
Directory Manager is not a privileged role inside 389 Directory Server. It is the account that exists outside the access-control system entirely — the superuser DN that ACIs do not constrain, used to bootstrap the directory and repair it when its own permissions are broken. Obtaining it is not privilege escalation within a directory. It is the point at which the directory stops being an authority about anything, because every answer it gives afterward could have been written by the person asking.
What makes this bug worth studying is that the authentication check works correctly. SASL PLAIN receives cn=Directory Manager with the wrong password, evaluates it, and rejects the bind. The failure is not in the decision; it is in what the failed decision leaves behind. The identity from the rejected attempt stays in a Cyrus SASL auxiliary property on the connection, and the next successful bind — “regardless of which SASL mechanism completes that second bind,” in Red Hat’s words — picks it up. This is an error-path cleanup defect wearing an authentication bypass’s clothes, and it belongs to a family that keeps recurring: code that is careful about the success path and casual about state left over from failure.
The choice of second bind is what removes the last obstacle. A reader skimming “following a subsequent successful bind” might reasonably assume the attacker needs some credential to produce that success. They do not. SASL ANONYMOUS is a bind that succeeds by design while proving nothing, and Red Hat names it explicitly in the attack sequence. The precondition that sounds like a barrier is a single unauthenticated round trip.
That has a direct consequence for anyone reaching for the obvious defense. Disabling anonymous binds is the standard hardening answer to almost every LDAP problem, and it is the right instinct — but the description closes it off in its own last sentence: “A variant using a valid low-privileged account’s own successful bind instead of an anonymous one is also possible.” In a directory, a valid low-privileged account is not a scarce resource. It is every employee. The mitigation Red Hat actually offers targets the first step instead, removing PLAIN from the mechanisms the server will negotiate at all.
That mitigation is better than the network-segmentation advice Red Hat is giving for the FreeIPA flaw published the same day, because it is narrow and it addresses the mechanism rather than the reachability. It also carries a wrinkle worth stating plainly. The statement says the attack requires “no non-default configuration” — which means the exposure exists where nsslapd-allowed-sasl-mechanisms has never been set, and where it is unset the server offers whatever Cyrus SASL makes available. So the fix-by-configuration requires administrators to introduce an explicit allow-list into deployments that, by the vendor’s own account, mostly do not have one. Before setting it, you have to know which mechanisms your clients genuinely use, and getting that list wrong takes the directory down for everyone.
One more line in the statement deserves reading closely: full Directory Manager privileges “over an LDAPS connection.” Transport encryption is not a mitigating factor here, and organizations that treat LDAPS-only as a hardening milestone should note that it does not touch this. Nor does the record carry any CISA KEV fields — cisaExploitAdd, cisaActionDue, cisaVulnerabilityName and cisaRequiredAction are all absent from NVD — and no exploitation has been reported by any vendor, agency, or researcher. This is severity without observed attacks, which is the window in which acting is cheapest.
What to do
- Set
nsslapd-allowed-sasl-mechanismsexplicitly, listing only the mechanisms your clients use and excluding PLAIN. Red Hat’s examples are GSSAPI, EXTERNAL, and GSS-SPNEGO. Confirm what is actually in use from your access logs before you set it — an incomplete list breaks binds. - Do not treat disabling anonymous binds as the mitigation. Red Hat’s own description says the attack also works using a valid low-privileged account’s successful bind.
- Check what you are running. Red Hat lists Directory Server 13 as not affected; Directory Server 11 and 12 and the
389-ds-basepackages on RHEL 6 through 10 are affected, with no fix in any stream as of today. - Search access logs for the shape of the attack: a failed SASL PLAIN BIND followed on the same connection by a successful BIND, and any operation attributed to
cn=Directory Managerfrom a source that has no business issuing one. - Restrict access to the Cockpit 389 Console and to delegated LDAP add and rename privileges, per Red Hat’s workaround for CVE-2026-19843. Plain deployments without the console are unaffected by that one.
- Restrict LDAP on 389 and 636 to trusted hosts while no package exists, and track Red Hat’s CVE pages for errata directly — these records have no CPE data while they sit in
Received, so CPE-matching scanners will not flag them.
Sourcing note
Checked: the NVD API record for CVE-2026-18922, retrieved September 7, 2026, showing vulnStatus Received, lastModified equal to its publication timestamp, and no CISA KEV fields; Red Hat’s CVE page for the same; and Red Hat’s CSAF VEX documents for CVE-2026-18922, CVE-2026-19843, CVE-2026-18355 and CVE-2026-76560 at security.access.redhat.com, which are the source for all product-status counts and remediation text. Every description, statement, and mitigation passage above is quoted verbatim from Red Hat’s records.
Could not reach: no Red Hat errata exists for any of these CVEs; a search of Red Hat’s advisory index returned only RHSA-2026:36195, a 389-ds-base update issued July 7, 2026 for CVE-2026-11610 and CVE-2026-11774, which are unrelated. Bugzilla 2511388 is referenced by the CVE-2026-18922 record but was not read. cisa.gov returns 403 to automated fetching, so KEV status is taken from the CISA fields republished inside NVD, where they are absent.
Unresolved: the CVE-2026-18453 entry above is summarized from Red Hat’s published CVE listing rather than from its own VEX document, which was not separately retrieved; its affected-product counts are therefore not stated here. Third-party vulnerability aggregators list a CVE-2026-18043 for a Cockpit 389 LDAP editor command injection that appears to describe the same defect as CVE-2026-19843; no Red Hat record for that identifier was found, and this story reports only the identifier Red Hat itself published. Product counts are Red Hat’s figures as retrieved today and will move as triage continues.