What is the CVSS score of CVE-2026-50202?

CVE-2026-50202 has a CVSS 3.1 base score of 5.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2026-50202?

Yes, a patch is available for CVE-2026-50202. Update the affected software to the latest version immediately.

Steeltoe CVE-2026-50202

EUVD-2026-37817 MEDIUM

Exposure of Resource to Wrong Sphere (CWE-668)

2026-06-17 GitHub_M

GHSA-7fqc-p256-7pwj

Information Disclosure Steeltoe Security Authentication Cloudfoundrybase Steeltoe Security Authentication Jwtbearer Steeltoe Security Authentication Openidconnect Steeltoeoss

5.9

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

5.9 MEDIUM

AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

6.8 MEDIUM

Multi-scheme deployment plus kid collision required (AC:H); attacker needs only a valid token from one co-configured IdP (PR:L, not PR:H); no availability impact applies.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Jul 02, 2026 - 22:02 EUVD

Source Code Evidence Fetched

Jun 17, 2026 - 23:04 vuln.today

Analysis Generated

Jun 17, 2026 - 23:04 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Cross-authority JWT signing key confusion in Steeltoe authentication libraries allows tokens issued by one identity provider to be accepted by application schemes configured for a different authority. Affected are CloudFoundryBase prior to 3.4.0, JwtBearer prior to 4.2.0, and OpenIdConnect prior to 4.2.0 when deployed in multi-scheme configurations. No public exploit has been identified at time of analysis; vendor patches are available and no CISA KEV listing exists.

Technical ContextAI

The vulnerability resides in the TokenKeyResolver class shared across the three affected Steeltoe NuGet packages (CPE: cpe:2.3:a:steeltoeoss:steeltoe.security.authentication.cloudfoundrybase, cpe:2.3:a:steeltoeoss:steeltoe.security.authentication.jwtbearer, cpe:2.3:a:steeltoeoss:steeltoe.security.authentication.openidconnect). The root cause maps to CWE-668 (Exposure of Resource to Wrong Sphere): the JWT signing key cache used a ConcurrentDictionary<string, SecurityKey> indexed solely by the kid (Key ID) JWT header value, with no authority URL included in the cache key and no expiration policy. In ASP.NET Core applications registering multiple JwtBearer schemes pointing to distinct identity providers, this shared namespace means a resolved key fetched for authority A will satisfy cache lookups initiated by scheme B if both IdPs happen to use the same kid string. The commit diff at 04db2ace confirms the fix: composite cache keys are now formed by combining the authority URI with the kid (via GetCacheKey(tokenKeysUri, keyId)), the unbounded ConcurrentDictionary is replaced with MemoryCache carrying a 12-hour TTL for found keys and 30-60 second TTL for not-found entries, and the resolver is registered as a singleton shared across all schemes rather than being instantiated per-scheme.

RemediationAI

Upgrade to the patched releases: Steeltoe.Security.Authentication.CloudFoundryBase 3.4.0, Steeltoe.Security.Authentication.JwtBearer 4.2.0, and Steeltoe.Security.Authentication.OpenIdConnect 4.2.0. These versions introduce authority-namespaced cache keys and bounded TTL expiration, eliminating both the cross-authority confusion and the stale-key retention issues. Fix commits are available at https://github.com/SteeltoeOSS/Steeltoe/commit/04db2ace3b806bfe0260bb7d4bda340f241eff48 and https://github.com/SteeltoeOSS/Steeltoe/commit/17b27b8be546ae3f83a2f6e91d45e0c84c5314b7. If immediate upgrade is not possible, two compensating controls apply: (1) Restrict each application instance to a single JwtBearer scheme - this eliminates the cross-authority cache collision vector but requires architectural changes in multi-IdP deployments and may not be feasible without application refactoring; (2) Restart the application process immediately after any identity provider signing key rotation - this flushes the unbounded ConcurrentDictionary cache, preventing post-rotation stale key acceptance, but is purely reactive and requires operational discipline to execute consistently. Neither workaround addresses both attack vectors simultaneously.