PyJWT CVE-2026-102274

Exploitation requires that the application parses an attacker-influenceable JWK Set via PyJWT's PyJWKSet.from_dict/from_json or PyJWKClient.get_jwk_set (versions 2.9.0-2.13.0, with the 'cryptography' backend installed), and that the attacker can place a malformed RSA JWK - d/e/n present with an incorrect private exponent and missing CRT parameters (p, q, dp, dq, qi) - into that set alongside valid keys. The key LIMITING factor is control over JWKS content: in typical deployments the JWKS is fetched over TLS from a trusted identity provider, so practical risk is confined to scenarios with a compromised/poisoned JWKS endpoint, a MITM position, multi-tenant or user-supplied key sources, or JWKS served without transport integrity. No authentication or user interaction is required by the library itself (CVSS PR:N/UI:N), and impact is availability-only (authentication outage / request-level DoS), recoverable once the malformed key is removed or PyJWT is upgraded to 2.14.0.

Signals are consistent and point to a genuine but moderate-severity availability issue rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) describes a network-reachable, low-complexity, unauthenticated defect with availability-only impact and no confidentiality or integrity loss - matching CWE-755 (improper handling of an exceptional condition). EPSS is low at 0.35% (26th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; SSVC reinforces this with Exploitation=poc, Automatable=no, Technical Impact=partial. A public PoC exists (gist by alon710), so 'publicly available exploit code exists' - but PoC availability must not be conflated with active exploitation. The one point of friction worth stating explicitly: the CVSS A:H (total availability loss) is somewhat stronger than SSVC's 'partial' technical impact, and real-world reachability is gated on the attacker being able to influence the contents of the JWK Set that the application parses (typically served by a trusted IdP over TLS), which the base CVSS vector's PR:N/AV:N does not capture. Net: a real but low-urgency patch-soon issue (availability only, no code execution, low EPSS, no KEV, exploitation not automatable), not a drop-everything priority.

An application uses PyJWT's PyJWKSet/PyJWKClient to load a JWK Set, and an attacker who can influence that JWKS content (e.g., a poisoned or compromised JWKS endpoint, a MITM position, or a multi-tenant/attacker-supplied key source) inserts a single malformed RSA JWK - one supplying d/e/n with an incorrect private exponent and no CRT parameters - alongside the otherwise valid keys. When PyJWKSet.__init__ constructs the set, RSAAlgorithm.from_jwk triggers cryptography's rsa_recover_prime_factors, which raises a plain ValueError that PyJWKSet's 'except PyJWTError' guard does not catch, aborting parsing of the entire set and causing authentication failures / request-level denial of service. A public PoC demonstrating the uncaught ValueError is available.