CVE-2026-102265 in PyJWT
Summary
by MITRE • 09/29/2026
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWS._load in jwt/api_jws.py is affected because parser catches ValueError but not RecursionError. This occurs when a deeply nested token header reaches json.loads. As a result, RecursionError escapes the documented PyJWT error hierarchy. Consequently, an unauthenticated malformed token can cause a request-level failure and HTTP 500. This issue is fixed in version 2.14.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within PyJWT versions ranging from 2.13.0 to 2.14.0 stems from an incomplete exception handling mechanism during the parsing of JSON Web Tokens, specifically affecting the _load method located in jwt/api_jws.py. This function is responsible for decoding and validating JWS signatures by first loading the token header using Python's standard json.loads routine. While the implementation correctly anticipates and catches ValueError exceptions which typically arise from malformed or invalid JSON structures, it fails to account for RecursionError instances that can be triggered under specific conditions involving deeply nested data structures within the token header. This oversight represents a gap in defensive coding practices where only expected error types are handled while runtime limit errors remain uncaught.
The technical flaw manifests when an attacker submits a maliciously crafted JWT with a header containing excessively deep nesting levels, such as arrays or objects embedded recursively to extreme depths. When json.loads processes this input, it exceeds Python's default recursion limit for stack depth, triggering a RecursionError that propagates up the call stack without being intercepted by the application logic. Because PyJWT does not catch this specific exception type within its error handling block, the unhandled exception bubbles up through the web framework layer rather than being converted into a standard authentication or validation failure response. This behavior deviates from the documented error hierarchy of the library and exposes internal implementation details to the end user via raw stack traces or generic server errors.
From an operational perspective, this vulnerability allows for a denial-of-service attack against services that rely on PyJWT for token verification without requiring any form of authentication prior to validation. An unauthenticated actor can send repeated requests containing these deeply nested tokens to exhaust application resources and cause consistent HTTP 500 Internal Server Error responses across the affected endpoints. This not only disrupts service availability but also potentially leaks sensitive information about the underlying Python environment, framework versioning, or internal code paths through detailed error messages if debug modes are enabled in production environments. The impact is particularly severe for high-traffic applications where such requests can be amplified to create significant load on backend systems attempting to parse and reject these malformed inputs.
This issue aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the application fails to properly handle a specific class of exceptional conditions that are technically possible within valid input domains but lead to unintended system states. Furthermore, it relates to CWE-209: Generation of Error Message Containing Sensitive Information if the resulting HTTP 500 response includes stack traces or internal details in production configurations. In terms of MITRE ATT&CK mapping, this vulnerability facilitates a Denial of Service via resource exhaustion (T1499) and potentially aids in reconnaissance through error-based information leakage (T1608). The attack vector is classified as Network Access with Low Complexity since it requires only the ability to send HTTP requests containing crafted headers.
Mitigation strategies primarily involve upgrading PyJWT to version 2.14.0 or later, where this exception handling gap has been addressed by explicitly catching RecursionError alongside ValueError and other expected parsing exceptions. For organizations unable to immediately upgrade due to dependency constraints, implementing a custom middleware or wrapper around the token validation logic can provide temporary protection. This workaround should intercept HTTP requests before they reach the JWT verification step and validate header complexity limits programmatically, rejecting tokens with headers exceeding a predefined nesting depth threshold. Additionally, ensuring that web frameworks are configured to return generic error pages without stack traces in production environments reduces the informational leakage risk associated with this vulnerability. Regular auditing of third-party library exception handling practices is recommended to identify similar gaps where runtime errors might escape application-level controls and impact service stability or security posture.