CVE-2026-102266

PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key 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.

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:

{"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.prepare_key. With the default enforce_minimum_key_length=False, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.

An attacker can independently calculate HMAC-SHA256(b"", signing_input) 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.prepare_key](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:

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

with InvalidKeyError.

Empty oct JWKs decode to the same key but are accepted

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

For:

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

the empty Base64URL value is decoded to:

b""

and returned without an emptiness check.

[PyJWK.__init__](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jwk.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._verify_signature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jws.py#L389-L416) has a separate path for PyJWK objects.

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

prepared_key = key.key

The value is not passed through:

alg_obj.prepare_key(key.key)

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

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

The verifier therefore receives:

b""

as the HS256 key.

This creates the following difference for identical cryptographic key material:

raw b""
    -> HMACAlgorithm.prepare_key
    -> InvalidKeyError

{"kty":"oct","k":""}
    -> HMACAlgorithm.from_jwk
    -> b""
    -> PyJWK.key
    -> PyJWS._verify_signature…

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:

{"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.prepare_key. With the default enforce_minimum_key_length=False, PyJWT emits a warning and proceeds with HMAC verification using the zero-length key.

An attacker can independently calculate HMAC-SHA256(b"", signing_input) 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.prepare_key](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:

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

with InvalidKeyError.

Empty oct JWKs decode to the same key but are accepted

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

For:

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

the empty Base64URL value is decoded to:

b""

and returned without an emptiness check.

[PyJWK.__init__](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jwk.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._verify_signature](https://github.com/jpadilla/pyjwt/blob/7144e4534c34810f4525dc4578a32addd8212cff/jwt/api_jws.py#L389-L416) has a separate path for PyJWK objects.

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

prepared_key = key.key

The value is not passed through:

alg_obj.prepare_key(key.key)

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

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

The verifier therefore receives:

b""

as the HS256 key.

This creates the following difference for identical cryptographic key material:

raw b""
    -> HMACAlgorithm.prepare_key
    -> InvalidKeyError

{"kty":"oct","k":""}
    -> HMACAlgorithm.from_jwk
    -> b""
    -> PyJWK.key
    -> PyJWS._verify_signature…

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.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key 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.

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.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key 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.

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

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

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)