VDB
KO
MEDIUM 5.9

GHSA-7fqc-p256-7pwj

Steeltoe's static JWKS cache shared across schemes and never invalidated

Details

### Summary

The JWT signing key cache in `TokenKeyResolver` uses `kid` as the sole cache key without namespacing by authority. In applications with multiple `JwtBearer` schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another. Additionally, cached keys have no expiration, so rotated or revoked keys remain trusted until the application process restarts.

### Impact

In multi-scheme deployments, an attacker who controls one identity provider's signing key can forge tokens accepted by other schemes within the same application. For all applications using `TokenKeyResolver`, a signing key removed from the identity provider's JWKS endpoint remains trusted indefinitely.

### Mitigations

If an immediate upgrade is not possible:

- In multi-scheme deployments, configure only one `JwtBearer` scheme per application when different identity providers are required. - Restart the application process after an identity provider signing key rotation to clear stale cached keys.

Are you affected?

Enter the version of the package you're using.

Affected packages

NuGet / Steeltoe.Security.Authentication.JwtBearer
Introduced in: 0 Fixed in: 4.2.0
Fix dotnet add package Steeltoe.Security.Authentication.JwtBearer --version 4.2.0
NuGet / Steeltoe.Security.Authentication.OpenIdConnect
Introduced in: 0 Fixed in: 4.2.0
Fix dotnet add package Steeltoe.Security.Authentication.OpenIdConnect --version 4.2.0
NuGet / Steeltoe.Security.Authentication.CloudFoundryBase
Introduced in: 0 Fixed in: 3.4.0
Fix dotnet add package Steeltoe.Security.Authentication.CloudFoundryBase --version 3.4.0

References