Intelligence
AEV-2026-0056

389 Directory Server's SASL PLAIN handling could install a failed Directory Manager bind's stale identity on a later, unrelated successful bind (CVE-2026-18922)

GitHub Security Advisory GHSA-pr87-24g5-hphv formally documents CVE-2026-18922, CVSS 9.8 Critical, CWE-287, against 389 Directory Server: a stale identity carried in a Cyrus SASL auxiliary property from a failed SASL PLAIN bind claiming cn=Directory Manager can be installed on a connection once a later, unrelated bind, anonymous or a valid low-privileged account, succeeds on the same connection. This entry could not independently confirm the source-level mechanism, since access.redhat.com, bugzilla.redhat.com and nvd.nist.gov were each blocked to direct fetch in this session and no fix commit exists yet to read.

Candidate: below the publication gate, not a published vulnerabilityConfirmedStatus: candidateEvent: 7 September 2026Agent IdentityExecution Authority

Affected

Organisation
Red Hat / 389ds
Product
389 Directory Server (389-ds-base)
Component
SASL PLAIN authentication handling, specifically its use of the Cyrus SASL auxiliary property store
Versions
unknown
Configurations
Any 389 Directory Server or Red Hat Directory Server deployment accepting SASL PLAIN binds over a connection that can also carry a subsequent SASL bind of any mechanism

Execution authority facts

Fields the evidence does not establish are shown as unknown rather than guessed.

Intended task
Authenticate a directory-server connection to whatever principal a given bind attempt actually, successfully establishes
Agent
The 389 Directory Server process handling the connection's SASL bind sequence
Delegating actor
unknown
Action
Per GHSA-pr87-24g5-hphv's own description: a SASL PLAIN bind claiming cn=Directory Manager with an incorrect password fails, and a stale identity artifact from that failed attempt, carried in a Cyrus SASL auxiliary property, is not cleared; a subsequent, unrelated bind on the same connection, a SASL ANONYMOUS bind or a valid low-privileged account's own successful bind, then succeeds, and the server installs the first attempt's stale Directory Manager identity rather than the second bind's own authenticated principal
Target resource
The connection's own effective, installed authentication identity, and everything that identity can subsequently reach as cn=Directory Manager
Environment
unknown
Credentials used
None valid for Directory Manager: the advisory's own documented sequence requires only an incorrect password for the first, failed bind, and either no credential (SASL ANONYMOUS) or a genuine, unrelated low-privileged account's own valid credential for the second, successful bind
Privileges available
Full Directory Manager authority, 389 Directory Server's own highest-privilege built-in identity, per the advisory's own stated consequence
Authority presented
No valid Directory Manager credential at any point: the first bind claiming that identity failed, and the second, successful bind's own credential (or lack of one, for the anonymous variant) never claimed or required Directory Manager authority
Authority required
A validly authenticated Directory Manager credential, which the advisory's own account confirms was never presented
Applicable policy
unknown
Approval mechanism
unknown
Required approver
unknown
Independent approval
unknown
Action binding
unknown
Sequence context
Two sequential bind attempts on one shared, still-open connection: a failed SASL PLAIN bind claiming cn=Directory Manager, followed by a distinct, unrelated, successful bind of a different mechanism or identity

Impact

Consequence
Full compromise of a directory server's own highest-privilege built-in identity, cn=Directory Manager, with no valid credential ever presented for it, per GHSA-pr87-24g5-hphv's own CVSS 9.8 Critical score
Reach
organisational
Reversibility
unknown
Detectability
unknown
Propagation
A concrete path exists, per the advisory's own documented sequence, from an unauthenticated or low-privileged connection to full Directory Manager authority, but this entry did not observe the effect actually spreading to a further system
Recovery
Unknown. No fixed release or patched version was identified as available at the time of this entry; access.redhat.com, bugzilla.redhat.com and nvd.nist.gov, three sources most likely to carry a Red Hat mitigation statement or an upstream patch reference, were each blocked to direct fetch in this session.

Evidence

Primary sources

Reproduction status
Not independently reproduced against a running 389 Directory Server instance. This entry's own account rests on GHSA-pr87-24g5-hphv's own structured record, fetched directly, corroborated by several independently phrased web searches converging on identical wording for the mechanism, CVSS score and CWE classification.
Evidence state
Confirmed

Known unknowns

  • Whether this has been exploited against a real 389 Directory Server or Red Hat Directory Server instance.
  • Whether a fixed release or patched package exists.
  • The exact affected version range.
  • Whether Amazon Linux or any other downstream distribution has issued a corresponding advisory.
  • The exact source file, function, or auxiliary-property field the underlying mechanism involves, since no fix commit exists yet for an equivalent direct reading.

Limitations

  • access.redhat.com, bugzilla.redhat.com and nvd.nist.gov, three sources most likely to carry Red Hat's own CVE statement, the underlying Bugzilla report (BZ#2511388), and NVD's own record, were each blocked to direct fetch by this session's own network egress policy on every attempt.
  • This entry did not clone 389ds/389-ds-base and could not independently confirm the exact source-level mechanism the advisory's own prose describes, since no fix commit or patched release exists yet for an equivalent direct reading.

Claim provenance