Bug 2554718 - [Minor Incident] CVE-2026-18922 389-ds-base: 389-ds-base: SASL PLAIN authentication allows privilege escalation to Directory Manager via stale identity in Cyrus SASL auxiliary property [fedora-all]
Summary: [Minor Incident] CVE-2026-18922 389-ds-base: 389-ds-base: SASL PLAIN authenti...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Viktor Ashirov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["452862bb-cfc8-4278-a2c7-3...
Depends On:
Blocks: CVE-2026-18922
TreeView+ depends on / blocked
 
Reported: 2026-10-18 06:28 UTC by Avinash Hanwate
Modified: 2026-10-19 07:51 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-10-19 07:51:51 UTC
Type: ---
Embargoed:
fedora-admin-xmlrpc: mirror+


Attachments (Terms of Use)

Description Avinash Hanwate 2026-10-18 06:28:24 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

A flaw was found in 389 Directory Server (389-ds-base). During SASL PLAIN authentication, the ids_sasl_canon_user() function writes the resolved bind DN into a Cyrus SASL auxiliary property (prop_set) on every canonicalization attempt, including failed ones. A failed one-shot PLAIN exchange does not trigger SASL-context recreation in ids_sasl_check_bind() -- that only happens when CONN_FLAG_SASL_COMPLETE or continuing is already set. A subsequent successful SASL bind on the same connection retrieves the auxiliary property via prop_getnames() and unconditionally trusts only the first stored value (dnval[0].values[0]), with no check on which SASL mechanism completed the second exchange and no check that the value corresponds to the identity actually just authenticated.

An unprivileged remote attacker can exploit this with zero valid credentials: first send a SASL PLAIN bind as cn=Directory Manager with an incorrect password (fails as expected, but leaves the Directory Manager DN in slot 0 of the auxiliary property), then complete a SASL ANONYMOUS bind on the same connection. The server installs the stale Directory Manager identity instead of the anonymous identity, granting full Directory Manager authority. This was independently confirmed by Red Hat Product Security in an isolated, network-disconnected sandbox against 389-ds-base-2.9.0: "Who Am I?" returned "cn=directory manager", and the Directory-Manager-only cn=config attribute nsslapd-rootdn became readable. The same stale-identity mechanism also allows escalation via a valid low-privileged account's own successful second bind (originally reported variant, requiring one valid account), independently reproduced against the reporter's own PoC.

Root cause: ldap/servers/slapd/saslbind.c, ids_sasl_canon_user() (identity write, unconditional per mechanism) and ids_sasl_check_bind() (identity read-back and installation, no mechanism check, no freshness check). Verified directly against commit 33c0e0115c03017ba94ee02f144383704de32a25; unchanged since a September 2024 logging-format cleanup.


Note You need to log in before you can comment on or make changes to this bug.