PyJWT EUVD-2026-88478

Exploitation requires the target application to validate JWTs using PyJWKClient (e.g. get_signing_key_from_jwt) against a remotely hosted JWKS endpoint, and to expose that validation path to attacker-supplied tokens. No authentication and no valid token are needed because the 'kid' is taken from the unverified token header (verify_signature=False), so any attacker-chosen unknown kid triggers a forced refresh. JWKS caching being enabled does NOT protect the app - in 2.13.0 even a repeated identical unknown kid re-fetches on every call. Limiting factors: the application must actually use the remote-JWKS PyJWKClient pattern (apps using static/HMAC keys or local key sets are unaffected), and impact is amplification/resource consumption rather than code execution or data exposure; the fix also allows setting cooldown_duration=0 to disable the new throttle, which would reintroduce exposure.

This is a genuine but moderate-severity availability issue, not a critical priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) correctly reflects a remote, low-complexity, unauthenticated resource-exhaustion flaw (CWE-770) with no confidentiality or integrity impact. Signals are largely consistent: SSVC marks Exploitation=poc, Automatable=yes, and Technical Impact=partial, which aligns with a verified proof-of-concept in the GHSA advisory and an amplification (not full-compromise) outcome. The CVSS A:H rating sits in mild tension with SSVC's 'partial' technical impact - the real effect is request amplification against the victim app and its JWKS endpoint rather than a guaranteed total outage, so A:H may overstate impact. EPSS is low (0.35%, 27th percentile) and the CVE is NOT on CISA KEV, indicating no evidence of widespread active exploitation despite public PoC availability. Note also that this is explicitly an incomplete-fix follow-up to CVE-2026-48524 (fixed in 2.13.0); the 2.13.0 fix closed one amplification path but did not add the negative-cache/rate-limit mitigation, so environments that patched to 2.13.0 remain exposed and must upgrade to 2.14.0.

An attacker repeatedly sends unauthenticated requests carrying JWTs whose header 'kid' is unknown (or varies) to an application that validates tokens via PyJWKClient.get_signing_key_from_jwt against a remote JWKS endpoint. Because the header is read with verify_signature=False and unknown kids force a cache-bypassing refresh (lru_cache does not cache the raised exception), each request triggers a fresh outbound JWKS HTTP fetch plus full JSON parse, letting low-volume attacker traffic amplify into sustained load on both the victim server and the JWKS provider. A working proof-of-concept verified on 2.13.0 is published in the GHSA advisory.