PyJWT Asymmetric-PEM Detection Bypass Leading to Algorithm Confusion
An incomplete asymmetric-key guard in PyJWT (CVE-2026-102268) allows specially formatted public keys to be used as HMAC secrets, enabling universal token forgery when applications misconfigure algorithm allow-lists.
CVE search metadata
CVE search record: CVE-2026-102268. Severity: critical. CVSS: 9.1. KEV: no. Product: PyJWT (<= 2.13.0), PyJWT (2.13.0). Brief: PyJWT Asymmetric-PEM Detection Bypass Leading to Algorithm Confusion. Brief link: https://feed.craftedsignal.io/briefs/2026-09-pyjwt-pem-bypass/
CVE search record: CVE-2022-29217. Severity: high. CVSS: 7.4. EPSS: 1.35%. KEV: no. Product: PyJWT (<= 2.13.0), PyJWT (2.13.0). Brief: PyJWT Asymmetric-PEM Detection Bypass Leading to Algorithm Confusion. Brief link: https://feed.craftedsignal.io/briefs/2026-09-pyjwt-pem-bypass/
What's new
PyJWT versions 2.13.0 and earlier contain a security bypass in the is_pem_format utility that allows asymmetric public keys to be treated as symmetric HMAC secrets. This occurs because the library's internal regex-based PEM validator is overly strict, failing to recognize PEM-formatted keys that include marker-adjacent whitespace, bare carriage returns, or single-line folding. While the cryptography library correctly parses these mutated keys, PyJWT's guard mechanism - intended to prevent CVE-2022-29217 algorithm confusion - erroneously concludes they are not asymmetric keys. If an application's jwt.decode configuration includes both HMAC (e.g., HS256) and asymmetric algorithms, an attacker can leverage the public key as an HMAC secret to mint valid tokens with arbitrary claims. This vulnerability is critical for applications that fail to follow RFC 8725 best practices regarding algorithm allow-listing.
Attack Chain
- The attacker identifies an application that performs JWT verification with an overly permissive algorithm allow-list containing both asymmetric (e.g., RS256/ES256) and symmetric (e.g., HS256) algorithms.
- The attacker obtains the application's public verification key.
- The attacker applies specific whitespace or line-ending mutations to the public key PEM to bypass PyJWT's
is_pem_formatregex validation. - The attacker sends a malicious JWT, using the mutated public key as the HMAC shared secret to sign the token with
alg=HS256. - The target application receives the JWT and passes the mutated key to
PyJWT.decode. - The
HMACAlgorithm.prepare_keyfunction checks the mutated key againstis_pem_format, which returnsFalsedue to the mutation. - The guard logic is bypassed, allowing the public key bytes to be used directly as the HMAC secret.
- The application verifies the forged token as authentic, resulting in unauthorized access or privilege escalation.
Impact
Successful exploitation allows for universal token forgery, enabling an attacker to bypass authentication and impersonate any user, including high-privileged accounts. The vulnerability affects any service using PyJWT where developers have combined symmetric and asymmetric algorithms in the verification allow-list. While no active real-world incident was documented in the advisory, the potential impact is critical for any system relying on affected versions of PyJWT for identity or session management.
Recommendation
- Upgrade PyJWT to version 2.14.0 or later immediately to incorporate the fix for CVE-2026-102268.
- Audit all JWT verification logic to ensure algorithm allow-lists strictly adhere to RFC 8725, explicitly separating symmetric and asymmetric key paths.
- Avoid mixing HMAC and RSA/ECDSA algorithms in a single allow-list entry.
- Transition to the
PyJWKverification path, which enforces strict algorithm binding and is unaffected by this vulnerability.
Immediate actions
Upgrade PyJWT to 2.14.0 or later
Mitigations
Remove HMAC algorithms from allow-lists that accept asymmetric keys
CVE-2026-102268