PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. This is the same class of vulnerability as CVE-2025-59420 (Authlib), which received CVSS 7.5 (HIGH).
The wrong string if check is run for iss checking, resulting in "acb" being accepted for "abc".
What kind of vulnerability is it? Who is impacted? Disclosed by Aapo Oksman (Senior Security Specialist, Nixu Corporation). PyJWT supports multiple different JWT signing algorithms. With JWT, an attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify "jwt.algorithms.get_default_algorithms()" to get support for all algorithms. They can also specify a single one of …
In PyJWT 1.5.0 and below the invalid_strings check in HMACAlgorithm.prepare_key does not account for all PEM encoded public keys. Specifically, the PKCS1 PEM encoded format would be allowed because it is prefaced with the string —–BEGIN RSA PUBLIC KEY—– which is not accounted for. This enables symmetric/asymmetric key confusion attacks against users using the PKCS1 PEM encoded public keys, which would allow an attacker to craft JWTs from scratch.
It is possible for an attacker to bypass verification when "a token digitally signed with an asymetric key (RS/ES family) of algorithms but instead the attacker send a token digitally signed with a symmetric algorithm (HS* family)". It is also possible for an attacker to create his own signed token with any payload he wants and have it considered valid using the "none" algorithm.