PyJWT EUVD-2026-90388

Requires PyJWT 2.11.0 through 2.13.0 AND a specific application coding pattern: the consuming app must (1) call decode()/decode_complete() with a mutable options mapping where verify_signature is false, then (2) reuse that SAME mapping object for a subsequent call after setting verify_signature to true. Under those conditions _merge_options() has already mutated the mapping so verify_exp/verify_nbf/verify_iat/verify_aud/verify_iss/verify_sub/verify_jti stay false. Limiting factors: applications that create a fresh options mapping per decode call are entirely unaffected; the token must still carry a valid signature for the correct key (this is not a signature bypass); and the payoff is limited to bypassing registered-claim checks (accepting expired/wrong-audience/wrong-issuer tokens).

This is a genuine but conditional integrity flaw, not a broad-impact critical. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N, base 6.5) correctly captures the tension: it is network-reachable and needs no privileges (PR:N), but AC:H reflects that exploitation depends entirely on a specific application-side anti-pattern - the app must reuse the SAME mutable options mapping across decode() calls and toggle verify_signature from false back to true. Applications that build a fresh options dict per call (the documented/common usage) are not affected at all. Critically, this is NOT a signature-verification bypass: the attacker's token must still be validly signed with the correct key; only the registered-claim checks (exp/nbf/iat/aud/iss/sub/jti) get silently disabled. No EPSS score, no CISA KEV listing, and no public exploit code were provided - exploitation status is 'no public exploit identified at time of analysis'. The 'Information Disclosure' tag understates and mischaracterizes the issue: the impact is integrity of claim validation (I:H, C:L), i.e. accepting expired or wrong-audience/issuer tokens, not data leakage. Net real-world priority is low-to-medium: high-prevalence library, but the exploit is gated behind a non-default coding mistake in the consuming application.

A Python service using PyJWT 2.11.0-2.13.0 constructs one options dict (e.g. {'verify_signature': False}) to peek at a token, then reuses that same dict object for a later authenticated decode() with verify_signature flipped to true. Because the earlier call mutated the dict in place, verify_exp/aud/iss/etc. remain false, so the service now accepts a correctly-signed but expired or wrong-audience token. No public exploit code exists; success requires the attacker to hold a validly signed token whose registered claims would normally be rejected.