Modification of Assumed-Immutable Data (MAID)PyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Modification of Assumed-Immutable Data (MAID) in the _merge_options() method in jwt/api_jwt.py, which writes verify_exp, verify_nbf, verify_iat, verify_aud, verify_iss, verify_sub, and verify_jti directly onto the caller's options dictionary when verify_signature is falsy, with no dict(options) copy before those writes. An attacker can have an expired token, or one carrying the wrong audience, issuer, subject, or jti, accepted by a call that explicitly asks for full verification, because an earlier call sharing that same dictionary object left the claim checks switched off in it. This requires the application to reuse one mutable options dictionary across decode calls with differing intent, where an earlier call disabled signature verification and a later one requests full verification, a shape that arises with shared configuration objects or wrapper instances rather than freshly built literals.
How to fix Modification of Assumed-Immutable Data (MAID)? Upgrade PyJWT to version 2.14.0 or higher.
| |
Regular Expression Denial of Service (ReDoS)Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via is_pem_format in jwt/utils.py, which previously used a regex (_PEM_RE) that accepted PEM formatting variants recognised by the underlying cryptography loader but not explicitly validated by pyjwt. An attacker with high privileges can supply a key in one of these loader-accepted PEM variants to trigger a crash, causing a denial of service.
How to fix Regular Expression Denial of Service (ReDoS)? Upgrade pyjwt to version 2.14.0 or higher.
| |
Open RedirectPyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Open Redirect via the fetch_data method in jwt/jwks_client.py, which follows HTTP redirects when fetching a JWK Set from a remote URI. An attacker who can influence the JWKS endpoint URL or perform a MitM attack can redirect the request to an arbitrary server, causing the client to send its request headers (potentially including authorization or other sensitive headers) to an attacker-controlled host, and to accept a forged JWK Set that undermines signature verification.
How to fix Open Redirect? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via the _verify_signature method in jwt/api_jws.py when a PyJWK object is used to verify an HMAC-signed token. In the vulnerable code path, key.key is used directly without passing it through alg_obj.prepare_key(), which means the minimum HMAC key-length check is bypassed. An attacker can supply a weak or undersized HMAC key that would normally be rejected, potentially forging or accepting invalid signatures and compromising both confidentiality and integrity.
Note: This is only exploitable when a PyJWK object is passed directly to the verification call, as the minimum HMAC key-length check does not reject the key under the default configuration in that code path.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via is_pem_format() in jwt/utils.py, which fails to recognize certain loader-accepted PEM formatting variants as valid PEM. The fix for CVE-2022-29217 rejects an asymmetric key passed to an HMAC algorithm only when is_pem_format() identifies the key as PEM-encoded. Because the old regex does not match all PEM variants that the underlying cryptography library's loader accepts, an attacker can supply a non-standard but loader-accepted PEM key to bypass the asymmetric-key-as-HMAC-secret guard, enabling signature forgery.
Note: This is only exploitable when the application accepts a user-influenced key or algorithm selection that allows an asymmetric public key to be used as an HMAC secret.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Handling of Exceptional ConditionsPyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Handling of Exceptional Conditions via the PyJWK constructor in jwt/api_jwk.py when processing a JWK set containing a malformed key. An attacker who can supply a JWK set with a malformed entry causes an unhandled ValueError to propagate out of Algorithm.from_jwk, crashing the application.
How to fix Improper Handling of Exceptional Conditions? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via the prepare_key method in jwt/algorithms.py, where DER-encoded public keys are accepted as HMAC secrets without rejection. An attacker who controls a public key (e.g. an RSA or EC public key in DER format) can supply it as the HMAC secret to forge valid JWT signatures, because the library computes an HMAC over the token using the public key bytes rather than a private secret. This allows full authentication bypass by producing tokens that pass signature verification.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.14.0 or higher.
| |
Incorrect Behavior Order: Validate Before CanonicalizePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Incorrect Behavior Order: Validate Before Canonicalize via the _load method in jwt/api_jws.py, which accepts non-canonical base64url-encoded JWS segments. Because the library does not verify that a decoded-then-re-encoded segment round-trips to the original input, an attacker can supply a JWT whose header, payload, or signature segment is a non-canonical base64url encoding that decodes to the same bytes as a legitimate token. This allows the attacker to forge or manipulate tokens in ways that bypass integrity checks, leading to limited confidentiality and integrity impact.
How to fix Incorrect Behavior Order: Validate Before Canonicalize? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via the prepare_key method in jwt/algorithms.py, where a public JWK container (such as a JWK Set with a kty member nested inside a JSON array or deeply nested object) is not rejected when supplied as an HMAC secret. An attacker who controls the key material can pass a public asymmetric key as the HMAC secret, enabling signature forgery by exploiting the algorithm confusion between asymmetric and symmetric key types.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.14.0 or higher.
| |
Uncontrolled RecursionPyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Uncontrolled Recursion via the _load method in jwt/api_jws.py when parsing a JWT with a deeply nested recursive JSON structure in the header. An attacker can supply a JWT whose header contains deeply nested JSON objects, triggering unbounded recursion in the JSON parser and causing a RecursionError that crashes the process. Prior to the fix, RecursionError was not caught alongside ValueError, so it propagated as an unhandled exception instead of being converted to a DecodeError.
How to fix Uncontrolled Recursion? Upgrade PyJWT to version 2.14.0 or higher.
| |
Uncaught ExceptionPyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Uncaught Exception via _decode_payload in jwt/api_jwt.py, where a JWT token containing a deeply nested JSON payload triggers an unhandled RecursionError during json.loads parsing. An attacker can crash the application by submitting a token whose payload is a recursively nested JSON structure, causing an uncaught exception that propagates out of the decode path.
How to fix Uncaught Exception? Upgrade PyJWT to version 2.15.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via the prepare_key method in jwt/algorithms.py, where an encoded JWK (such as an RSA public key) is accepted as a valid HMAC secret without rejection. An attacker who knows the target application's RSA public key can supply it as the HMAC secret to forge JWT tokens with arbitrary claims, which a verifier configured with a mixed algorithm set (e.g., algorithms=["HS256", "RS256"]) will accept as valid.
Note: This is only exploitable when the verifier is configured to accept both an asymmetric algorithm (e.g., RS256) and a symmetric HMAC algorithm (e.g., HS256) simultaneously.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.14.0 or higher.
| |
Improper Verification of Cryptographic SignaturePyJWT is a Python implementation of RFC 7519.
Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature via the from_jwk function in jwt/algorithms.py when loading an OKP (Octet Key Pair) private key from a JWK. The function constructs the private key from the d parameter without verifying that the supplied public key component x matches the public key derived from d, allowing an attacker to supply a JWK where the private and public key components are inconsistent. This mismatch can be exploited to bypass signature verification, as the public key used for verification does not correspond to the private key used for signing.
How to fix Improper Verification of Cryptographic Signature? Upgrade PyJWT to version 2.15.0 or higher.
| |
Allocation of Resources Without Limits or ThrottlingAffected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via PyJWKClient.get_signing_key in jwt/jwks_client.py, where an attacker can repeatedly present tokens with unknown key IDs, causing the client to perform an unbounded number of forced refreshes against the JWKS endpoint. Each unrecognised kid triggers a fresh HTTP fetch with no rate limiting or cooldown, allowing an attacker to exhaust the server's resources or cause excessive outbound network traffic.
How to fix Allocation of Resources Without Limits or Throttling? Upgrade pyjwt to version 2.14.0 or higher.
| |
