Steeltoe's static JWKS cache shared across schemes and never invalidated
Description
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Security.Authentication.CloudFoundryBase prior to version 3.4.0, Steeltoe.Security.Authentication.JwtBearer prior to version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect prior to version 4.2.0, 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. Steeltoe.Security.Authentication.CloudFoundryBase version 3.4.0, Steeltoe.Security.Authentication.JwtBearer version 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect version 4.2.0 patch the issue. If an immediate upgrade is not possible: In multi-scheme deployments, configure only one JwtBearer scheme per application when different identity providers are required; and/or restart the application process after an identity provider signing key rotation to clear stale cached keys.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1- Range: <3.4.0 (CloudFoundryBase), <4.2.0 (JwtBearer and OpenIdConnect)
Patches
Vulnerability mechanics
Root cause
"JWT signing key cache uses only the kid as the cache key without namespacing by authority and without expiration."
Attack vector
An attacker can craft a JWT with a `kid` value that matches a key cached from a different identity provider. Because the cache key is only the `kid` without the authority, the token may be validated against the wrong provider's key, allowing forged tokens to be accepted. Additionally, since cached keys never expire, a rotated or revoked key remains trusted until the application restarts. [ref_id=1] [ref_id=2]
Affected code
The vulnerability resides in `TokenKeyResolver` (JwtBearer/OpenIdConnect) and `CloudFoundryTokenKeyResolver` (CloudFoundryBase). Both classes cached JWT signing keys using only the `kid` as the cache key, without namespacing by authority, and cached keys had no expiration. [patch_id=6466799] [patch_id=6466800]
What the fix does
Both patches replace the static `ConcurrentDictionary` with a `MemoryCache` that uses a composite cache key combining the authority URL and the `kid` (e.g., `"{tokenKeysUri}:{keyId}"`), preventing cross-scheme cache collisions. They also introduce configurable time-to-live values: 12 hours for found keys and 30–60 seconds (with jitter) for not-found keys, ensuring rotated or revoked keys are eventually re-fetched. [patch_id=6466799] [patch_id=6466800]
Preconditions
- configApplication must be configured with multiple JwtBearer schemes pointing to different identity providers.
- inputAttacker must be able to submit a JWT whose kid matches a key cached from a different authority.
Generated on Jun 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- github.com/SteeltoeOSS/Steeltoe/commit/04db2ace3b806bfe0260bb7d4bda340f241eff48mitrex_refsource_MISC
- github.com/SteeltoeOSS/Steeltoe/commit/17b27b8be546ae3f83a2f6e91d45e0c84c5314b7mitrex_refsource_MISC
- github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-7fqc-p256-7pwjmitrex_refsource_CONFIRM
News mentions
0No linked articles in our index yet.