CVE-2026-48523

PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

[!NOTE] Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.

PyJWT 2.9.0 through 2.12.1 allows a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow.

Summary

PyJWT's PyJWK verification path allows a verifier-side algorithm allow-list bypass.

In affected versions, when a JWT is decoded with a PyJWK object, PyJWT verifies that the header alg string is present in the caller's algorithms=[...] list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the PyJWK object.

This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header advertises an allowed algorithm. This affects the documented PyJWKClient usage flow and does not require any non-default flags or unsafe configuration.

Details

In jwt/api_jws.py in 2.12.1, _verify_signature() treats PyJWK keys differently from normal PEM/public-key inputs:

if algorithms is None and isinstance(key, PyJWK):
    algorithms = [key.algorithm_name]

...

if not alg or (algorithms is not None and alg not in algorithms):
    raise InvalidAlgorithmError("The specified alg value is not allowed")

if isinstance(key, PyJWK):
    alg_obj = key.Algorithm
    prepared_key = key.key
else:
    alg_obj = self.get_algorithm_by_name(alg)
    prepared_key = alg_obj.prepare_key(key)

This logic means:

1. The JWT header alg is checked only as a string against the caller-supplied allow-list.
2. If the key is a PyJWK, the actual verifier is not selected from the header algorithm.
3. Instead, PyJWT always verifies with key.Algorithm, which is fixed when the PyJWK object is created.

PyJWK binds its algorithm in jwt/api_jwk.py from the JWK's alg field or from key-type defaults:

if not algorithm and isinstance(self._jwk_data, dict):
    algorithm = self._jwk_data.get("alg", None)

...

self.algorithm_name = algorithm
self.Algorithm = get_default_algorithms()[algorithm]
self.key = self.Algorithm.from_jwk(self._jwk_data)

So once a PyJWK is constructed, the verifier uses the PyJWK's bound algorithm, not the JWT header algorithm.

The issue is reachable through the documented JWKS flow. In docs/usage.rst, the project documents:

signing_key = jwks_client.get_signing_key_from_jwt(token)
jwt.decode(
    token,
    signing_key,
    audience="https://expenses-api",
    options={"verify_exp": False},
    algorithms=["RS256"],
)

PyJWKClient.get_signing_key_from_jwt() returns a PyJWK, so this documented path is affected.

This is not a "no-key forgery" issue. The attacker still needs control of an accepted JWK/JWKS private key. However, that is realistic in deployments such as:

• self-service OAuth client assertions
• multi-tenant key registration
• federation / BYO-JWKS trust models
• any system where external parties sign JWTs with their own registered keys

In those cases, the attacker can bypass verifier-side algorithm policy. For example, if the server intends to only accept PS256, an attacker controlling an accepted RSA JWK can sign with RS256, set alg=PS256 in the JWT header, and…

PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

TuxCare rebuilt pyjwt to address 4 CVEs. Fixed in 2.10.1.post2+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-48523 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)