PyJWT EUVD-2026-88479

Exploitation requires the target application to parse an attacker-supplied JWT before signature verification - specifically code paths using PyJWKClient.get_signing_key_from_jwt(token) (the documented JWKS verification flow) or any call to jwt.decode(token, options={"verify_signature": False}), and secondarily PyJWKClient.fetch_data against a malicious JWKS endpoint. No valid signature, credentials, JWKS network lookup, or user interaction is needed, and the crash fires during payload parsing on default configurations. Limiting factors: the vulnerable library version must be PyJWT >= 2.0.0a1 and <= 2.14.0 (fixed in 2.15.0, which already protected the JWS header path in 2.14.0 but not the payload path), the application must actually invoke one of these pre-verification parse paths on untrusted input, and impact is confined to availability (worker crash / HTTP 500) with no data exposure or code execution.

This is a genuine but moderate-priority availability issue, not a confidentiality/integrity breach. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the advisory: a single unauthenticated ~50KB network request with no user interaction crashes the auth handler, and impact is strictly availability (C:N/I:N), which matches CWE-248 (uncaught exception → HTTP 500 / dead worker). The signals pull in different directions on urgency. On the elevating side, SSVC marks the flaw Automatable:yes and publicly available exploit code exists (a cve-search gist), meaning weaponization is trivial and repeatable. On the moderating side, EPSS is only 0.29% (20th percentile) and the CVE is NOT in CISA KEV, so there is no confirmed active exploitation - the real-world driver here is low observed exploitation despite easy reproducibility, consistent with a DoS-only bug that yields disruption rather than data or code execution. SSVC Technical Impact is rated 'partial,' aligning with availability-only consequences. Net: treat as a priority patch for internet-facing services that call PyJWKClient.get_signing_key_from_jwt or jwt.decode(..., verify_signature=False) on attacker-supplied tokens, but it does not carry the breach risk of an RCE or auth-bypass. No conflicting data between CVSS and description was identified - the network/unauthenticated vector is corroborated by the advisory's reproduction notes.

An attacker sends an unauthenticated HTTP request carrying a forged JWT whose payload segment is valid JSON nested ~20,000 levels deep (roughly 50KB). When the service calls PyJWKClient.get_signing_key_from_jwt or jwt.decode with verify_signature=False, json.loads raises a RecursionError that the ValueError-only handler misses, escaping as an undocumented exception and crashing the worker with an HTTP 500. Public proof-of-concept exploit code exists and the payload needs no valid signature or network access to the JWKS endpoint, so the crash is trivially repeatable to cause sustained denial of service.