CVE-2026-102274: Denial of Service via Unhandled Exception in PyJWT JWK Set Parser

JSON Web Key Sets (JWKS) are used by modern web applications to dynamically fetch and cache public keys published by Identity Providers (IdPs). This mechanism allows applications to verify JSON Web Tokens (JWTs) without hardcoding cryptographic keys. In PyJWT, this JWK Set parsing and management logic is handled by the PyJWKSet class, which exposes a vital attack surface.

The vulnerability identified as CVE-2026-102274 represents a flaw classified under CWE-755: Improper Handling of Exceptional Conditions. When parsing a JWK Set, the parsing loop is designed to catch PyJWT-specific errors, allowing individual malformed or unsupported keys to be skipped so that the application can still load other valid keys. However, certain cryptographic validation failures raise a built-in Python ValueError instead of a custom library exception.

Because ValueError does not inherit from PyJWT's custom base exception class PyJWTError, it bypasses the exception handler within the parser loop. This unhandled exception immediately bubbles up to the calling application, halting the parsing process entirely. Consequently, a single malformed JWK in a set of otherwise valid keys will cause the entire JWK Set initialization to fail.

At the core of the vulnerability is how PyJWT handles RSA keys that contain a private exponent d but lack Chinese Remainder Theorem (CRT) parameters. When such a key is encountered, the RSAAlgorithm.from_jwk function in jwt/api_jwk.py is executed to rebuild the complete key structure. This function relies on the underlying Python cryptography library's rsa_recover_prime_factors function to reconstruct the missing parameters.

If the provided value for d is mathematically incompatible with the modulus n or the public exponent e, the cryptographic calculation fails. This failure is signaled by the cryptography library throwing a standard Python ValueError. This standard error represents an exceptional condition that PyJWT's wrapper does not anticipate or map.

In PyJWT versions 2.9.0 through 2.13.0, the parser loop only catches PyJWTError when initializing each PyJWK object within a PyJWKSet. Since ValueError is a standard Python built-in exception and does not inherit from PyJWTError, the exception escapes the loop. The lack of strict error mapping at the level of the cryptographic backend caller causes the failure to cascade up the call stack, aborting the loading of all subsequent valid keys.

The vulnerability exists inside the PyJWK constructor. Below is an analysis of the vulnerable and patched code paths.

Prior to the patch, the constructor of PyJWK in jwt/api_jwk.py resolved the algorithm and constructed the key directly:

# Vulnerable Code in PyJWT <= 2.13.0
class PyJWK:
    def __init__(self, jwk_data: JWKDict, algorithm: str | None = None) -> None:
        # ... algorithm resolution ...
        self.key = self.Algorithm.from_jwk(self._jwk_data)

In this implementation, any exception raised during self.Algorithm.from_jwk that is not a subclass of PyJWTError escapes the initializer. The fix implemented in version 2.14.0 addresses this by wrapping the call in a try-except block:

# Patched Code in PyJWT >= 2.14.0
class PyJWK:
    def __init__(self, jwk_data: JWKDict, algorithm: str | None = None) -> None:
        # ... algorithm resolution ...
        try:
            self.key = self.Algorithm.from_jwk(self._jwk_data)
        except ValueError as error:
            raise InvalidKeyError(
                f"Unable to construct key from JWK: {error}"
            ) from error

By trapping ValueError and converting it into InvalidKeyError (which inherits from PyJWTError), the patch ensures that the parsing loop in PyJWKSet can catch the exception, log the invalid key, and safely continue to parse the remaining valid keys in the JWKS payload.

Exploitation of CVE-2026-102274 depends on the target application's configuration for resolving JWK Sets. If the application fetches a JWK Set from an external, untrusted, or user-configurable URI, an attacker can exploit this behavior. The attacker must possess the ability to inject or host a malformed JWKS payload containing at least one malformed RSA key.

To craft a triggering key, the attacker defines a JSON object with "kty": "RSA", a valid public modulus "n", a valid public exponent "e", but a mathematically invalid private exponent "d". Crucially, the standard CRT parameters (p, q, dp, dq, qi) must be omitted. This omission forces the library to call rsa_recover_prime_factors during parsing, which triggers the target mathematical calculation.

When the target application performs token verification and retrieves the JWK Set, PyJWT attempts to process the keys. The parser encounters the malformed key, raises an unhandled ValueError, and crashes the token verification routine. This results in a request-level Denial of Service, returning a 500 Internal Server Error to the user and preventing any legitimate JWTs within that set from being validated.

The impact of CVE-2026-102274 is classified as a Denial of Service (DoS) affecting application availability. Although there is no risk of remote code execution or data confidentiality loss directly through this flaw, the impact on authentication services is high. In systems where authentication relies on a shared, dynamic JWKS, a single malicious JWK can lock out all users of the service.

The CVSS v3.1 score of 5.9 reflects this specific impact profile. The attack vector is Network, but the complexity is High because the attacker must find a way to make the application parse a malicious JWK Set (e.g., via multi-tenant environments or IDP manipulation). No special privileges or user interactions are required to trigger the failure once the key is in the parser's path.

The Exploit Prediction Scoring System (EPSS) score of 0.00352 indicates a relatively low probability of exploitation in the wild, largely because the attack complexity relies on specific application architectures. However, for vulnerable multi-tenant software as a service (SaaS) or API gateways that fetch external JWKS, the flaw represents a reliable way to disrupt authentication availability.

The definitive remediation for CVE-2026-102274 is upgrading to PyJWT version 2.14.0 or later. This version correctly translates any ValueError raised by the underlying cryptographic libraries during key creation into a manageable InvalidKeyError, preventing parser loop abortion.

If an immediate upgrade is not feasible, several defensive workarounds can be applied. Applications should avoid dynamic JWK Set loading from untrusted or user-supplied URLs. Implementing strict input validation on JWKS endpoints, or caching only verified public keys, significantly reduces the attack surface.

Furthermore, implementing robust error handling around JWT verification routines ensures that even if PyJWKSet parsing fails, the error is caught at the application layer. This prevents the application process from crashing and allows for graceful degradation, such as falling back to secondary authentication providers or returning structured error messages without dropping the daemon process.