PyJWT EUVD-2026-32918

The attacker must control a registered JWK or JWKS private key that the target application trusts - this is the PR:L (low privilege) requirement confirmed by the CVSS vector. The application must be using the PyJWKClient.get_signing_key_from_jwt() flow specifically, and must call jwt.decode() or jwt.decode_complete() with a PyJWK key object as confirmed by the vulnerability description. The affected version range is strictly 2.9.0 through 2.12.1; deployments outside this range are not affected. Exploitation is limited to parties who are already enrolled as valid key holders - unauthenticated external attackers with no registered key cannot exploit this bypass. Applications that use raw string or bytes keys (rather than PyJWK objects) with jwt.decode() are not affected by this specific code path.

The CVSS 5.4 Medium score is supported by the vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N: the attack is network-reachable, requires no user interaction, and has low complexity, but requires low-level privileges (PR:L), meaning the attacker must already control a registered JWK key in the target application's JWKS. The confidentiality and integrity impacts are limited (C:L/I:L) and there is no availability impact. No EPSS score was provided in the input data, so probabilistic exploitation likelihood cannot be assessed quantitatively. The vulnerability is not listed in CISA KEV and no POC was identified. Despite the moderate CVSS score, the business risk to applications using PyJWKClient for algorithm-restricted verification is meaningful: a bypass of algorithm allow-listing could allow an enrolled party to use weaker or deprecated algorithms that the application explicitly prohibited, potentially undermining cryptographic security properties. Applications that do not use PyJWK objects or the PyJWKClient flow are not affected by this specific bypass path.

An attacker who has been issued a registered JWK key pair (or has compromised one) in an application's JWKS crafts a JWT: they sign the token using a cryptographically weak or explicitly-disallowed algorithm with their private key, but set the JWT header's alg field to an algorithm that is on the application's allow-list. When the application calls PyJWKClient.get_signing_key_from_jwt() followed by jwt.decode() with the allow-list, the allow-list check passes on the spoofed header value, and the signature verification succeeds because it uses the algorithm bound to the resolved PyJWK object rather than the header-declared one - resulting in the token being accepted despite violating the algorithm policy. No public proof-of-concept has been identified at time of analysis.