Steeltoe EUVD-2026-37817

Exploitation of the cross-authority confusion vector requires all of the following: (1) the application must register two or more JwtBearer authentication schemes each pointing to distinct identity provider authority URLs; (2) both identity providers must publish signing keys that share the same kid string value - either by coincidence or by attacker influence over one IdP's key naming convention; (3) the attacker must possess a valid JWT bearing that kid, issued by the IdP whose key is resolved and cached first. The stale-key vector has a lower bar: any application using affected versions where the configured IdP rotates its signing keys will continue to accept tokens signed by the old (revoked) key until the process restarts - this applies even to single-scheme deployments. Limiting factors: single-scheme deployments are not susceptible to the cross-authority confusion; kid collisions between unrelated IdPs are not guaranteed; and the CVSS AC:H metric explicitly reflects the non-default configuration dependency. The CVSS PR:H designation implies attacker-level control over an IdP, while the simpler collision scenario requires only holding a valid user-level token from one of the configured providers.

The provided CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N) scores 5.9, reflecting network exploitability against high-complexity, high-privilege conditions. AC:H is well-justified: exploitation requires both a multi-scheme deployment across distinct IdPs AND a kid collision between those providers - a configuration absent from the vast majority of single-IdP deployments. The PR:H designation appears to assume the attacker must exercise influence over one of the IdP's key naming (e.g., to manufacture a collision); for the simpler scenario where a collision occurs naturally, PR:L (holding a valid token from one IdP) is arguably sufficient - this inconsistency is worth flagging to defenders. No EPSS data was supplied; given AC:H and the specific deployment prerequisite, widespread opportunistic exploitation is implausible. The stale-key vector (rotated keys remaining trusted indefinitely until process restart) is a distinct, lower-barrier risk for any single-IdP deployment that rotates keys, as it requires only a valid pre-rotation token rather than a cross-IdP kid collision. No active exploitation is confirmed by CISA KEV and no public exploit code is known.

An attacker who holds a valid JWT from identity provider A - or who can influence IdP A's key naming - submits that token to an application endpoint whose JwtBearer scheme is configured for identity provider B. If both IdPs publish a signing key sharing the same kid string, the Steeltoe TokenKeyResolver returns the cached key fetched for IdP A in response to the validation lookup for scheme B, causing the ASP.NET Core middleware to accept the foreign token as valid for IdP B's audience. No public proof-of-concept code is known at time of analysis, but the attack requires only standard JWT construction tooling once a kid collision is identified.