CVE-2026-48522

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

[!NOTE] The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.

Summary

PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch.

If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:

1. Cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem) — the file's contents are passed to json.load.
2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface).
3. Forge tokens that PyJWT verifies as valid — if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and jwt.decode() accepts.

Affected versions

Tested and reproducible on PyJWT 2.11.0 and 2.12.1. Likely all versions back to PyJWKClient introduction.

Reproducer (full attack chain — verified empirically)

import jwt as pyjwt
from jwt import PyJWKClient
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization
import json, base64, time

# Attacker generates keypair (no relation to real IdP)
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub_n = key.public_key().public_numbers().n

def b64u(n):
    bl = (n.bit_length() + 7) // 8
    return base64.urlsafe_b64encode(n.to_bytes(bl, 'big')).rstrip(b'=').decode()

# Attacker writes JWK Set containing their public key to /tmp
jwks = {"keys":[{"kty":"RSA","kid":"attacker","use":"sig","alg":"RS256",
                  "n":b64u(pub_n),"e":"AQAB"}]}
with open("/tmp/attacker.json","w") as f:
    json.dump(jwks, f)

# Attacker mints token signed with their private key, jku=file://
priv_pem = key.private_bytes(serialization.Encoding.PEM,
    serialization.PrivateFormat.PKCS8, serialization.NoEncryption())
now = int(time.time())
token = pyjwt.encode(
    {"sub":"attacker","aud":"target-app","iat":now,"exp":now+3600},
    priv_pem, algorithm="RS256",
    headers={"kid":"attacker","jku":"file:///tmp/attacker.json","typ":"JWT"})

# Vulnerable application pattern: caller derives jku from token header
# and passes to PyJWKClient without scheme validation
header = pyjwt.get_unverified_header(token)
client = PyJWKClient(header["jku"])      # <-- accepts file:// silently
key_obj = client.get_signing_key_from_jwt(token)
decoded = pyjwt.decode(token, key_obj.key, algorithms=["RS256"],
                       audience="target-app")
print("Token verified:", decoded)
# Output: Token verified: {'sub': 'attacker', 'aud': 'target-app', ...}

Cross-library evidence — PyJWT is the outlier

The same composition pattern is structurally safe in 4 other mainstream JWT libraries:

| Library | Behavior on jku=file://... | Mechanism | |---|---|---| | PyJWT 2.12.1 (Python) | Reads file from disk, parses, uses for signature verification | urllib default OpenerDirector includes FileHandler | | panva/jose 6.2.3 (Node.js) | Refuses pre-fetch | WHATWG fetch() rejects non-http(s) at fetch-spec layer | | golang-jwt + MicahParks/keyfunc v3.4.0 (Go) | Refuses pre-fetch | http.DefaultTransport only registers http/https | | Microsoft.IdentityModel.Tokens 8.18.0 (.NET) | Refuses pre-fetch | HttpDocumentRetriever defaults RequireHttps=true | | Spring Security NimbusJwtDecoder 6.3.4 (Java)…

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):
 …

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

TuxCare rebuilt pyjwt to address 3 CVEs. Fixed in 2.3.0.post2+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-48522 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)