Steeltoe’s authentication libraries use a static cache of JWT signing keys, keyed solely by the token identifier (kid). In applications that configure multiple JWT bearer schemes, a key fetched for one identity provider can be reused to validate tokens issued by another provider because the cache does not namespace keys by authority. The cache entries never expire, so rotated or revoked keys remain trusted until the application process is restarted. This flaw allows an attacker who possesses a valid token from one provider to present that token to a different provider’s scheme, thereby gaining unauthorized access, or to continue using a revoked token after the provider has rotated its keys. The weakness is classified as CWE‑668. The likely attack vector is that an attacker supplies a token issued by a trusted identity provider to an application using multiple authentication schemes; this inference is based on the described interaction between schemes and the nature of JWT validation.

The vulnerability exists in Steeltoe OSS libraries: Steeltoe.Security.Authentication.CloudFoundryBase versions earlier than 3.4.0, Steeltoe.Security.Authentication.JwtBearer versions earlier than 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect versions earlier than 4.2.0. These libraries are used in cloud-native .NET applications to implement authentication against CF, JWT bearer, and OpenID Connect providers.

The CVSS base score is 5.9, indicating moderate severity, and the EPSS score of less than 1% implies a very low probability of exploitation at this time. The vulnerability is not listed in the CISA KEV catalog. However, because the flaw permits cross-provider token validation and staleness of revoked keys, the impact can be significant if an attacker can acquire a legitimate token from one authority. Exploitation requires supplying such a token and does not depend on arbitrary code execution. The lack of key expiration extends the window of opportunity until the application process restarts.