CVE-2026-50202: Steeltoe Auth Bypass Vulnerability

CVE-2026-50202 Overview

CVE-2026-50202 affects Steeltoe, an open source library suite for building cloud-native .NET applications. The vulnerability resides in the TokenKeyResolver component used by Steeltoe authentication packages. The JWT signing key cache uses kid (key ID) as the sole cache key without namespacing by authority. In applications configured with multiple JwtBearer schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another scheme. Cached keys also have no expiration, so rotated or revoked keys remain trusted until the application process restarts. The flaw is tracked under [CWE-668] Exposure of Resource to Wrong Sphere.

Critical Impact
Tokens issued by one identity provider may be accepted as valid by a different authentication scheme, enabling cross-tenant authentication bypass in multi-IdP deployments.

Affected Products

Steeltoe.Security.Authentication.CloudFoundryBase prior to version 3.4.0
Steeltoe.Security.Authentication.JwtBearer prior to version 4.2.0
Steeltoe.Security.Authentication.OpenIdConnect prior to version 4.2.0

Discovery Timeline

2026-06-17 - CVE-2026-50202 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-50202

Vulnerability Analysis

The Steeltoe authentication libraries cache JWT signing keys retrieved from identity provider JWKS endpoints. The TokenKeyResolver class indexes cached keys by the kid header value from the JWT alone. The cache does not partition entries by the issuing authority or scheme. When an application registers multiple JwtBearer authentication schemes for distinct identity providers, the resolver may return a signing key associated with one issuer to validate a token presented to another scheme. Attackers with valid credentials at one provider can craft tokens accepted by another protected resource.

A secondary defect compounds the impact. Cached signing keys have no time-to-live. After an identity provider rotates or revokes a signing key, the Steeltoe process continues to trust the previous key until the host process restarts.

Root Cause

The root cause is improper resource scoping in the in-memory key cache. The cache key derivation logic uses only the JWT kid claim and omits the authority or scheme identifier. This violates isolation expectations between authentication schemes and matches the [CWE-668] pattern of exposing a resource to the wrong sphere of control.

Attack Vector

Exploitation requires an attacker capable of obtaining a valid JWT from one of the trusted identity providers registered in the target application. The attacker submits this token to an endpoint protected by a different JwtBearer scheme. If the kid matches a previously cached key, validation succeeds against the wrong issuer context. The attack vector is network-based but requires high privileges and high attack complexity, since timing depends on cache state and matching kid values.

text

// Patch excerpt from JwtBearerAuthenticationBuilderExtensions.cs
 using Microsoft.AspNetCore.Authentication;
 using Microsoft.AspNetCore.Authentication.JwtBearer;
 using Microsoft.Extensions.DependencyInjection;
+using Microsoft.Extensions.DependencyInjection.Extensions;
 using Microsoft.Extensions.Options;

 namespace Steeltoe.Security.Authentication.JwtBearer;

Source: GitHub Commit 04db2ace

Detection Methods for CVE-2026-50202

Indicators of Compromise

Successful authentication events where the JWT iss claim does not match the configured authority of the validating scheme.
Authentication acceptance of tokens signed with signing keys that the identity provider has rotated or revoked.
Repeated cross-scheme requests presenting tokens with kid values that overlap between distinct identity providers.

Detection Strategies

Inventory all .NET applications using Steeltoe authentication packages and identify deployments registering more than one JwtBearer scheme.
Audit application logs for token validation success against endpoints where the presented iss claim differs from the scheme authority.
Correlate JWKS rotation events from identity providers with continued acceptance of prior keys by Steeltoe-protected services.

Monitoring Recommendations

Enable verbose logging on Microsoft.AspNetCore.Authentication.JwtBearer to capture token validation parameters and signing key identifiers.
Forward authentication telemetry to a centralized analytics platform such as Singularity Data Lake for cross-scheme correlation and anomaly detection.
Alert on authentication acceptance occurring after a documented IdP key rotation when the application has not been restarted.

How to Mitigate CVE-2026-50202

Immediate Actions Required

Upgrade Steeltoe.Security.Authentication.CloudFoundryBase to version 3.4.0 or later.
Upgrade Steeltoe.Security.Authentication.JwtBearer to version 4.2.0 or later.
Upgrade Steeltoe.Security.Authentication.OpenIdConnect to version 4.2.0 or later.
Restart all affected application processes immediately after upgrade to clear stale cached keys.

Patch Information

The maintainers released fixes in Steeltoe.Security.Authentication.CloudFoundryBase 3.4.0, Steeltoe.Security.Authentication.JwtBearer 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect 4.2.0. The CloudFoundryBase fix introduces Microsoft.Extensions.Caching.Memory to add cache expiration to CloudFoundryTokenKeyResolver. The JwtBearer fix adds expiration to JWT and OpenID key caching via Microsoft.IdentityModel.Tokens. See the GitHub Security Advisory GHSA-7fqc-p256-7pwj and the commit applying cache expiration.

Workarounds

Configure only one JwtBearer scheme per application when different identity providers are required across services.
Restart the application process after every identity provider signing key rotation to flush stale cached keys.
Segregate workloads that require distinct identity providers into separate processes or containers.

bash

# Update Steeltoe packages to patched versions via dotnet CLI
dotnet add package Steeltoe.Security.Authentication.JwtBearer --version 4.2.0
dotnet add package Steeltoe.Security.Authentication.OpenIdConnect --version 4.2.0
dotnet add package Steeltoe.Security.Authentication.CloudFoundryBase --version 3.4.0

# Restart the application to clear in-memory cached signing keys
systemctl restart my-steeltoe-app.service