CVE-2026-102274 in PyJWT
Summary
by MITRE • 09/29/2026
PyJWT is a Python implementation of JSON Web Token standards. From 2.9.0 until 2.14.0, PyJWKSet does not catch the plain ValueError raised for malformed RSA JWK components by RSAAlgorithm.from_jwk in jwt/api_jwk.py. This occurs when a JWK Set contains a malformed RSA key alongside otherwise usable keys. As a result, one malformed member aborts construction of the entire PyJWKSet. Consequently, applications can experience authentication failures or request-level denial of service. This issue is fixed in version 2.14.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within PyJWT versions ranging from 2.9.0 to 2.14.0 stems from an insufficient exception handling mechanism during the parsing and validation of JSON Web Key (JWK) sets. Specifically, when constructing a PyJWKSet object that contains multiple keys, the library relies on RSAAlgorithm.from_jwk to parse individual RSA key components defined in the JWK format. This internal method raises a plain ValueError exception if it encounters malformed or invalid RSA data within any single member of the set. The core technical flaw lies in the fact that PyJWKSet does not catch this specific ValueError, causing the entire construction process to abort immediately upon encountering the first malformed key.
This design oversight leads directly to an operational impact characterized by a denial-of-service condition for applications relying on dynamic JWK sets for authentication or authorization processes. In typical deployments where public keys are fetched from remote providers such as identity providers or OAuth2 servers, it is not uncommon for these endpoints to return mixed content containing both valid and invalid key entries due to misconfigurations or transitional states during key rotation. Because the presence of a single malformed RSA JWK member causes the entire set construction to fail, applications cannot proceed with validating tokens using any of the other valid keys present in the same response. This results in widespread authentication failures for legitimate users who are attempting to access protected resources, effectively creating a request-level denial-of-service scenario that disrupts service availability without requiring malicious exploitation beyond normal traffic patterns or minor server misconfigurations on the key provider side.
From a classification perspective, this vulnerability aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the software fails to handle an exceptional condition (malformed input data) gracefully within its control flow. It also relates to CWE-209: Generation of Error Message Containing Sensitive Information if the resulting traceback exposes internal stack details, although the primary impact here is availability rather than information disclosure. In terms of adversarial tactics, this flaw can be leveraged in attacks categorized under MITRE ATT&CK technique T1496: Resource Hijacking or more broadly as part of Availability-focused disruptions where an attacker might intentionally inject malformed keys into a JWK endpoint to disrupt service for downstream consumers who trust that specific provider.
To mitigate the risks associated with this vulnerability, organizations must ensure they upgrade PyJWT to version 2.14.0 or later, which implements proper exception handling to isolate errors in individual key parsing from the overall set construction process. For environments where an immediate upgrade is not feasible, developers should implement external validation layers that inspect incoming JWK sets for malformed components before passing them to the library. Additionally, implementing robust error handling and fallback mechanisms at the application level can help maintain availability by allowing services to continue operating with a subset of valid keys even if some entries in the set are corrupted or invalid. Regular monitoring of dependency versions and adherence to secure coding practices that anticipate partial data corruption in external inputs are critical steps in preventing similar issues in cryptographic libraries.