GHSA-7fqc-p256-7pwj
Steeltoe's static JWKS cache shared across schemes and never invalidated
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| NuGet | Steeltoe.Security.Authentication.JwtBearer | < 4.2.0 | 4.2.0 |
| NuGet | Steeltoe.Security.Authentication.OpenIdConnect | < 4.2.0 | 4.2.0 |
| NuGet | Steeltoe.Security.Authentication.CloudFoundryBase | < 3.4.0 | 3.4.0 |
Details
As written in the advisory (Markdown source, shown as plain text).
### 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.
References
External links from the advisory. They lead to third-party sites.
- https://github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-7fqc-p256-7pwj
- https://nvd.nist.gov/vuln/detail/CVE-2026-50202
- https://github.com/SteeltoeOSS/Steeltoe/commit/04db2ace3b806bfe0260bb7d4bda340f241eff48
- https://github.com/SteeltoeOSS/Steeltoe/commit/17b27b8be546ae3f83a2f6e91d45e0c84c5314b7
- https://github.com/SteeltoeOSS/security-advisories