CVE-2026-50202: Steeltoe JWT Cache Collision Enables Unauthorized Authentication Across Multiple Providers

Technical summary

The vulnerability exists in the `TokenKeyResolver` cache implementation across three Steeltoe authentication packages. The cache uses only the JWT key ID (`kid` claim) as the lookup key without including the authority (identity provider) as part of the cache key. This namespace collision means a signing key fetched from Identity Provider A is available in the cache for validation against tokens from Identity Provider B. Furthermore, cached keys lack any expiration or refresh logic, so key rotation at the identity provider does not invalidate cached copies. Exploitation requires an attacker to obtain a valid JWT signed with a key from one identity provider and present it to an application configured to trust a different provider that previously cached a key with the same `kid`. The attack surface is limited to multi-scheme JwtBearer deployments with distinct identity providers.

Business impact

The primary risk is unauthorized access in multi-tenant or multi-provider environments. An attacker who controls or compromises one identity provider's signing key could forge tokens accepted by applications also integrated with other identity providers. Organizations operating hybrid authentication architectures face elevated risk of lateral movement and privilege escalation. The indefinite caching of keys also extends the window of compromise after a provider detects and revokes a key, creating compliance and breach detection challenges. Impact is medium severity because exploitation requires high privilege (ability to obtain or sign tokens at one provider) and specific architectural conditions.

Affected systems

Steeltoe.Security.Authentication.CloudFoundryBase versions prior to 3.4.0, Steeltoe.Security.Authentication.JwtBearer versions prior to 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect versions prior to 4.2.0 are affected. Applications using these libraries are vulnerable only if configured with multiple JwtBearer authentication schemes backed by different identity providers. Single-scheme deployments or those using a single identity provider are not vulnerable. Organizations should audit their application configurations to determine whether they instantiate multiple distinct authentication pipelines pointing to different authorities.

Exploitability

Exploitation is not trivial and requires specific conditions: the attacker must obtain a valid JWT from one identity provider integrated with the target application, and the application must simultaneously trust a second identity provider that has previously cached a key with the same `kid` value. The CVSS vector (AC:H, PR:H) reflects these high barriers—the attacker needs high privileges and the conditions must align. No known public exploits exist, and the vulnerability is not tracked on the CISA KEV catalog. However, the flaw is straightforward to exploit in the right environment, and key collisions between providers are plausible in real-world scenarios.

Remediation

Upgrade to Steeltoe.Security.Authentication.CloudFoundryBase 3.4.0 or later, Steeltoe.Security.Authentication.JwtBearer 4.2.0 or later, or Steeltoe.Security.Authentication.OpenIdConnect 4.2.0 or later. Patched versions namespace the cache by both `kid` and authority, and implement cache expiration for rotated keys. Until an upgrade is possible, implement compensating controls: reduce configurations to a single JwtBearer scheme per application (deploy separate application instances if multiple providers are required), and establish a process to restart application processes immediately following identity provider key rotations to purge stale cache entries.

Patch guidance

Apply the vendor patches promptly to the affected Steeltoe NuGet packages. The patches modify the TokenKeyResolver cache implementation to include the token issuer (authority) as part of the cache key and add expiration logic. Verify the patch versions in your package manager—confirm CloudFoundryBase ≥ 3.4.0, JwtBearer ≥ 4.2.0, and OpenIdConnect ≥ 4.2.0. For applications with complex multi-provider setups, test the patches in a staging environment to ensure proper cache isolation before production deployment. Review your identity provider's key rotation schedule and ensure automated detection and restart procedures are in place.

Detection guidance

Monitor application logs for JWT validation errors that reference unexpected authorities or issuer mismatches—these may indicate cache pollution attempts. Log key cache hits and misses if instrumentation is available. In your identity provider's audit logs, correlate JWT validation failures with periods when keys were rotated to identify whether stale cached keys were being accepted. For network-based detection, inspect JWT claims in authentication traffic and flag tokens where the `iss` (issuer) claim does not align with the intended authentication scheme. Correlate successful authentications across provider boundaries as a potential signal of cache-based token smuggling.

Why prioritize this

Although the CVSS score is medium (5.9), prioritize this vulnerability in any environment running multi-scheme authentication with distinct identity providers. The flaw is subtle but high-impact: once exploited, it grants persistent access until remediation. Organizations should inventory their Steeltoe deployments and focus first on those with multiple JwtBearer configurations. Single-provider deployments can be deprioritized. The patch is straightforward and carries low regression risk, so upgrade scheduling should account for standard change management rather than emergency response timelines.

Risk score, explained

The CVSS 3.1 score of 5.9 (MEDIUM) reflects a network-accessible vulnerability (AV:N) with high attack complexity (AC:H) due to the need for specific multi-provider configuration and high required privileges (PR:H) to obtain a valid JWT from one provider. The impact is high for confidentiality and integrity (C:H, I:H) because compromised tokens grant unauthorized access and privilege escalation, but no availability impact (A:N). The scope is unchanged (S:U)—the vulnerability does not break out of the application boundary. The score appropriately captures that the flaw is serious in the wrong configuration but not universally exploitable.

Frequently asked questions