A stale principal's identity state survives a channel's own later, unrelated authentication event
A stateful channel that can carry more than one sequential authentication event over its own lifetime does not correctly reset identity state between them, so an identity artifact left behind by an earlier event, whether that event failed outright or simply belonged to a different principal, survives and is installed as the channel's effective identity once a later, unrelated event on the same channel actually succeeds.
Description
This weakness sits at a channel that is not a single request but a persistent, reusable object, a network connection, a session, a connection-pool member, a credential broker context, capable of carrying more than one sequential, independent authentication or principal-establishment event over its own lifetime. Each such event should decide the channel's effective identity fresh, from what that specific event itself established. This weakness appears when the channel instead retains an identity artifact from an earlier event, uncleared, and a later, different event's own success causes the server or client to install that earlier, stale artifact rather than the later event's own actually established principal. It is distinct from an authentication failure converted into an accepted authority state (AEW-016): AEW-016's own mechanism is a single check's own failure being read, on the identical call, as a result rather than a rejection, fabricating a substitute identity from nothing; here, the first event's own failure (or its own, different, otherwise legitimate success) is handled correctly by itself, and the corruption appears only downstream, at a second, separate, later event that itself succeeds on its own terms. It is distinct from a persistent effect surviving authority revocation (AEW-027): AEW-027's own mechanism is a durable, external store retaining a write made under illegitimate access after that access is later closed, read back afterward as trusted input; here there is no persistent store and no revocation event, only in-memory channel state carried between two sequential, live operations on a channel that never closed. It is distinct from delegated authority inherited without attenuation (AEW-006): AEW-006's own mechanism is a real, deliberate handoff of work or credentials from one legitimate actor to a second, distinct actor, whose own authority is never narrowed on the way; here there is no delegation, deliberate or otherwise, and no second actor receiving anything: a single channel's own later, independently authenticated event unintentionally inherits a state artifact its own success never earned. The corrective is structural rather than a missing check: fully reset or re-derive every authority-relevant identity artifact on a channel at the start of each new principal-establishment event, so that event's own success or failure is the only fact any later installed identity is ever drawn from.
The authority gap
The authority required is whatever the channel's own last successful principal-establishing event actually earned, and nothing more. The authority presented is a stale identity artifact left behind by a different, earlier event on the same channel, whether that earlier event failed outright or simply belonged to a different principal, and the two are treated as interchangeable because the channel itself stayed open across both.
Failure conditions
- A stateful channel (a network connection, a persistent session, a pooled connection, a credential broker context) can carry more than one sequential, independent principal-establishing event over its own lifetime.
- An earlier event on that channel leaves behind an identity artifact, whether that event failed outright or succeeded as a different principal, that is not fully cleared or reset before the channel's next principal-establishing event runs.
- A later, distinct event on the same channel succeeds on its own terms, establishing its own principal, but the system installs the earlier event's stale artifact as the channel's effective identity instead of, or in addition to, the later event's own actually established principal.
Consequences shown by the evidence
- A caller whose privileged authentication attempt failed nonetheless ends up with that attempt's own claimed authority, once any later, unrelated, genuinely successful authentication occurs on the same still-open channel.
- A channel's own effective identity becomes unpredictable from the sequence of events it has carried, rather than deterministically tied to whichever principal-establishing event actually, most recently succeeded.
Detection signals
- A stateful channel object (a connection, a session, a pooled resource) exposes or retains identity-relevant state across more than one sequential authentication attempt without an explicit reset between them.
- A fix for an incident adds an explicit clearing or re-derivation of identity state at the start of each new authentication attempt, where the prior code carried it forward implicitly.
- An authentication mechanism's own auxiliary or side-channel property store (a SASL auxiliary property, a session attribute, a connection-scoped cache) is written by one authentication path and read by the channel's own authorization logic without being scoped to a single attempt.
Known examples
- GitHub Security Advisory GHSA-pr87-24g5-hphv formally documents CVE-2026-18922 against 389 Directory Server (389-ds-base), published 7 September 2026, CVSS 9.8 Critical, CWE-287 Improper Authentication. 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: an attacker sends a SASL PLAIN bind claiming cn=Directory Manager with an incorrect password, the bind fails, the attacker then completes a SASL ANONYMOUS bind, or a valid low-privileged account's own successful bind, on the same connection, and the server installs the first attempt's stale Directory Manager identity rather than the second bind's own authenticated principal. No fixed version was available at the time this weakness was recorded, and this record could not independently confirm the exact source-level mechanism, since access.redhat.com, bugzilla.redhat.com and nvd.nist.gov were each blocked to direct fetch in this session on every attempt and no fix commit exists yet to read.