CVE-2026-102274: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-102274 is a Denial of Service vulnerability in PyJWT, a Python implementation of JSON Web Token standards, caused by improper handling of malformed RSA JWK components within a JWK Set. Affecting versions 2.9.0 through 2.13.0, the flaw causes PyJWKSet to abort construction of the entire key set when any single RSA key raises an uncaught ValueError, preventing valid keys from being loaded. The vulnerability was discovered and reported by SecDim Security Research, submitted on 2026-09-05, published to the GitHub Advisory Database on 2026-09-29, and fixed in PyJWT 2.14.0 released on 2026-09-11. It carries a CVSS v3.1 base score of 7.5 (High) per NVD, and 5.9 (Moderate) per the GitHub Advisory and ENISA, reflecting differing assessments of attack complexity (Github Advisory, Red Hat Bugzilla).

The root cause is improper handling of exceptional conditions (CWE-755) combined with an uncaught exception (CWE-248). In PyJWKSet.__init__ (jwt/api_jwk.py), the per-key error-skipping logic catches only PyJWTError subclasses; however, RSAAlgorithm.from_jwk in jwt/algorithms.py can raise a plain Python ValueError when processing an RSA private key that supplies d, e, and n without CRT parameters (p, q, dp, dq, qi) and where d is not the correct private exponent — causing rsa_recover_prime_factors to fail. Because ValueError is not a subclass of PyJWTError, it propagates uncaught out of the constructor, aborting the entire key-loading loop before any subsequent valid keys are processed. The vulnerability is reachable through the documented PyJWKClient.get_jwk_set flow, which feeds a fetched JWKS HTTP response directly into PyJWKSet.from_dict without per-key pre-validation (Github Advisory, PyJWT Commit).

Exploitation results in a request-level or persistent denial of service affecting JWT-based authentication services. When a JWK Set containing a malformed RSA key is parsed, no keys — including valid ones — are added to the resulting PyJWKSet, causing authentication failures for all requests that depend on that key set. There is no confidentiality or integrity impact; the vulnerability is purely an availability issue that can disrupt authentication infrastructure for applications using PyJWKClient or directly parsing externally sourced JWK Sets (Github Advisory, Red Hat Bugzilla).

A proof-of-concept demonstrating the bug is publicly available in the GitHub Security Advisory, showing that calling jwt.PyJWKSet.from_dict() with a crafted JWK Set containing a malformed RSA key triggers the uncaught ValueError. However, exploitation requires the attacker to be able to influence the JWK Set parsed by the application — for example, by injecting a malformed key into an aggregated or federated key set, or exploiting transit corruption of an unprotected JWKS endpoint. No in-the-wild exploitation has been confirmed, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.35–0.39%, indicating low near-term exploitation probability (Github Advisory).

1. Identify target: Locate an application using PyJWT versions 2.9.0–2.13.0 that fetches and parses a JWK Set from an external or controllable source (e.g., via PyJWKClient.get_jwk_set).
2. Craft malformed RSA JWK: Construct a JWK entry with kty: RSA, valid n and e fields, an invalid d value (e.g., "AAAAAA"), and no CRT parameters (p, q, dp, dq, qi).
3. Inject into JWK Set: Insert the malformed key into the JWK Set that the target application will parse — either by compromising the JWKS endpoint, performing a man-in-the-middle attack on an unprotected JWKS transport, or injecting into an aggregated/federated key set.
4. Trigger parsing: Cause the application to fetch and parse the poisoned JWK Set. RSAAlgorithm.from_jwk will call rsa_recover_prime_factors with the invalid d, raising ValueError: Unable to compute factors p and q from exponent d.
5. Achieve DoS: The uncaught ValueError propagates out of PyJWKSet.__init__, aborting key loading entirely. The application fails to construct any usable key set, causing authentication failures for all subsequent JWT verification requests (Github Advisory).

• Logs: Unhandled ValueError: Unable to compute factors p and q from exponent d appearing in application logs or Python tracebacks originating from jwt/algorithms.py (RSAAlgorithm.from_jwk) or jwt/api_jwk.py (PyJWKSet.__init__).
• Application Behavior: Sudden, widespread JWT authentication failures across all users or services relying on a specific JWK Set, without corresponding changes to application code or configuration.
• Network: Unexpected or anomalous content in JWKS endpoint responses, particularly RSA key entries lacking standard CRT parameters (p, q, dp, dq, qi) but containing a d field; unusual modifications to JWKS source URLs or DNS records pointing to attacker-controlled endpoints.
• File System: Unexpected modifications to locally cached JWKS files or configuration files specifying JWKS URIs (Github Advisory).

Upgrade PyJWT to version 2.14.0 or later, which wraps the key-construction call in PyJWK.__init__ to convert ValueError exceptions into InvalidKeyError (a PyJWTError subclass), allowing the existing per-key skip logic in PyJWKSet.__init__ to gracefully skip malformed keys while preserving valid ones (PyJWT Release, PyJWT Commit). As a workaround for applications that cannot immediately upgrade, validate and sanitize JWK Sets before passing them to PyJWT, ensuring each RSA key entry either includes all required CRT parameters or is pre-filtered. Additionally, ensure JWKS endpoints are served over TLS with integrity verification to prevent transit-based injection of malformed keys (Github Advisory).

The PyJWT maintainers reproduced and confirmed the vulnerability on 2026-09-08, characterizing it as a conditional availability failure rather than a signature-forgery or claims-verification bypass, and prepared a narrow fix (commit 8915570) that was released in version 2.14.0 on 2026-09-11. Red Hat tracked the issue via Bugzilla (Bug 2542691) with medium severity, and Microsoft also acknowledged the CVE in their security guidance. The vulnerability was discovered and responsibly disclosed by SecDim Security Research following a 90-day disclosure timeline (Github Advisory, Red Hat Bugzilla).