The First Bind Failed. The Second Bind Kept Its Identity Anyway.

A connection to a directory server is not, by itself, an identity. It becomes one only when something on that connection actually, successfully authenticates. CVE-2026-18922 is what happens when a directory server forgets that distinction between a claim and an achievement, and lets a claim that failed still count.

What the advisory states

GitHub Security Advisory GHSA-pr87-24g5-hphv, fetched directly in this session, formally documents CVE-2026-18922 against 389 Directory Server (389-ds-base), published 7 September 2026 and last updated 8 September 2026. Its structured record carries a CVSS score of 9.8, Critical, and a CWE-287, Improper Authentication, classification. Its own description states that 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.

Two authentication events, one connection, one stale artifact

SASL PLAIN authentication in a Cyrus SASL based server ordinarily populates an auxiliary property store with facts about the identity a bind attempt establishes, consumed elsewhere in the server to decide what authority the connection now carries. The advisory's own account is that this auxiliary state is not correctly reset when a bind attempt fails: an incorrect password for cn=Directory Manager causes the bind itself to fail, exactly as it should, but a stale fragment of that failed attempt's own identity claim remains associated with the connection rather than being cleared. A connection, unlike a single request, can carry more than one sequential authentication event over its own lifetime, and nothing in the documented mechanism prevents a second, entirely different bind, on the same still-open connection, from completing successfully while that stale fragment is still present. The advisory states the server then installs the first attempt's stale, higher-privilege identity, Directory Manager, rather than the second bind's own actually authenticated principal, and that this happens regardless of which SASL mechanism the second, successful bind itself uses.

Documented variants

The advisory's own account documents two ways the second, successful bind can occur: a SASL ANONYMOUS bind, which ordinarily carries no privilege at all, and a valid low-privileged account's own genuine, correctly authenticated bind. In both variants the second bind is real: whatever principal it establishes is the principal an implementation is required to install as the connection's effective identity. The vulnerability is not that the second bind was somehow itself illegitimate; it is that a completely unrelated prior failure, on the same connection, is allowed to override what the second bind actually, correctly earned.

What this record could and could not independently verify

This record attempted to independently corroborate the advisory's own account against Red Hat's own primary CVE record, the underlying Red Hat Bugzilla report the advisory's own upstream reference names (BZ#2511388), and the National Vulnerability Database's own entry. access.redhat.com, bugzilla.redhat.com and nvd.nist.gov were each blocked to direct fetch by this session's own network egress policy on every attempt, so this record's own account of the underlying Red Hat CVE state, the Bugzilla report's own comment history, and any upstream 389ds/389-ds-base fix commit or pull request rests on the GitHub Security Advisory Database's own structured record, fetched directly, corroborated by several independently phrased web searches that converged on identical wording for the mechanism, the CVSS score and the CWE classification. This record did not clone 389ds/389-ds-base and could not independently confirm the exact source file, function, or auxiliary-property field the advisory's own prose describes, and no fix commit or patched release exists at the time of this record for a diff to confirm the mechanism against. This record does not claim CVE-2026-18922 has been exploited against a real directory server, that a fixed release exists, that Amazon Linux or any other downstream distribution has shipped or scheduled a corresponding advisory, or that the exact affected code path matches any characterization beyond the advisory's own stated prose. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from how similar mechanisms have looked elsewhere.

The Authority Provenance ledger

Source principal (claimed). cn=Directory Manager, claimed by an attacker's own SASL PLAIN bind attempt with a password the advisory's own account states as incorrect, confirmed by the advisory as failing.

Interpreting action. 389 Directory Server's own SASL PLAIN authentication handling, specifically its handling of the Cyrus SASL auxiliary property store the advisory's own account states is not correctly reset on a failed bind, per GHSA-pr87-24g5-hphv's own prose; this record did not independently confirm the exact function or file, since no fix commit exists yet to read.

Semantic role before the crossing. A claimed, unauthenticated identity associated with one failed bind attempt on a connection, confirmed by the advisory as never actually validated: the password presented was wrong.

Semantic role after the crossing. The connection's own effective, installed identity for a second, later, genuinely successful bind that never itself claimed or required Directory Manager authority, per the advisory's own documented anonymous and low-privileged-account variants.

Execution principal and environment. The 389 Directory Server process itself, installing Directory Manager, the server's own highest-privilege built-in identity, as the connection's effective principal following the second bind, per the advisory's own stated consequence.

Failed limit. The connection's own authentication state was not reset, isolated, or re-derived from the second bind's own actually authenticated principal before that principal's authority was decided; a fact this record states directly from the advisory's own prose, unconfirmed at the source-code level.

Recovery path. Unknown. No fixed release, patched version, or upstream fix commit was identified as available at the time of this record; 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.

Recovery timing. Unknown, for the same reason.

Tracking state. CVE reserved 5 August 2026 per this record's understanding of the CVE program's own reservation practice; Red Hat/CVE publication 7 September 2026; GitHub Security Advisory Database record last updated 8 September 2026, the date this record was itself produced. This record does not independently confirm the CVE reservation date from a fetched primary source, since cve.org and the CVE program's own JSON record were not independently fetched in this session; it is stated here as the reservation date already understood at the point this record was assessed.

Exploitation. Unknown. No source available to this record states this mechanism has been exploited against a real 389 Directory Server or Red Hat Directory Server instance in the wild. The advisory documents an executable, concrete attack sequence; that is evidence of exploitability, not evidence of an observed production victim, and this record does not conflate the two.

Provenance evidence quality. Moderate. The mechanism, severity and CWE classification rest on a formally assigned CVE and a structured GitHub Security Advisory Database record, fetched directly and corroborated by independent web searches converging on identical wording, which this record treats as a credible, vendor-adjacent disclosure. It is weaker than this desk's own source-cloned CVE records: this record did not independently read 389ds/389-ds-base's own source, confirm the exact affected function, or confirm a fix, because 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 for an equivalent direct reading.

Beyond SASL: a stale principal surviving a channel's own next authentication event

The specific mechanism here is a Cyrus SASL auxiliary property on a directory-server connection. The shape underneath it is not specific to SASL, LDAP, or 389 Directory Server at all: any stateful channel that can carry more than one sequential principal-establishing event over its own lifetime, a persistent agent session reused across turns, an MCP or HTTP connection pool, a browser session, a PTY, an SSH connection, a credential broker context, a service-account context, a sub-agent delegation, or an approval cache, can carry the identical failure if an identity artifact left behind by one event, whether that event failed outright or simply belonged to a different principal, survives into a later, different, successfully authenticated event on that same channel. This desk has already recorded the adjacent claim that an identifier surviving unchanged across a resumed session is not, by itself, evidence that the underlying state was actually continued; CVE-2026-18922's own mechanism is that same failure mode's mirror image, an identity artifact surviving unchanged across a channel's own next authentication event, mistaken for evidence that the new event inherited it. This record adds src/content/moona-knowledge/principal-transition-authority.ts, a small, generic reasoning module with no SASL, LDAP or directory-server vocabulary anywhere in it, to make that distinction, claimed principal, authenticated principal, and effective principal, checkable the same way regardless of which stateful channel a scenario actually describes.

What this record does not establish

This record does not claim CVE-2026-18922 has been exploited in the wild, that a fixed 389-ds-base release or patched package exists at the time of this record, that Amazon Linux or any other downstream distribution has issued a corresponding advisory, that the exact affected source function or file matches any characterization beyond the advisory's own stated prose, or that Red Hat's own CVE record and Bugzilla report state anything beyond what this record could independently corroborate through the GitHub Security Advisory Database and web search, given that access.redhat.com, bugzilla.redhat.com and nvd.nist.gov were each blocked to direct fetch in this session on every attempt.