CVE-2026-102266: PyJWT 2.13.0 Accepts Empty HMAC Keys via JWK

CVE-2026-102266 is a high severity (CVSS 7.4) flaw in PyJWT 2.13.0. When a symmetric JWK has an empty key value, the JWK path accepts a zero-length HMAC key, so anyone can sign tokens that verify. The fix is PyJWT 2.14.0. Upgrade, and check that no empty key ever reaches your JWK Set.

What's affected

Per the GitHub advisory, the affected version is PyJWT 2.13.0 and the patched version is 2.14.0. The NVD text says "from 2.13.0 until 2.14.0", which is the same thing.

Exposure needs a specific setup. Your service must verify HS256 tokens using a symmetric JWK, through PyJWK or PyJWKSet, and one of those keys must be an oct key with an empty k value. The advisory gives a plausible cause: a missing configuration or secret-manager value that gets serialized as an empty string. The attacker does not need to control the JWK source.

How to check if you're exposed

Check the installed version and where you build JWKs:

pip show pyjwt
pip freeze | grep -i pyjwt
python -c "import jwt; print(jwt.__version__)"

Then look at your code and configuration for PyJWK, PyJWKSet and any place a symmetric key is read from an environment variable or secret store. Ask one question of each: could this value ever be empty? If so, fail startup rather than carry on.

What to do now

1. Upgrade PyJWT to 2.14.0 or later and rebuild your images.
2. Search for every place a symmetric key is loaded from configuration and make the service refuse to start if the value is empty.
3. Review your JWK Sets and secrets for any oct entry with an empty k.
4. Set enforce_minimum_key_length to true if your PyJWT version offers it. The advisory notes the default is false, which lets verification proceed with a warning.
5. If a key might have been empty in production, rotate it and review recently accepted tokens.

Why it matters

The advisory explains the inconsistency. A raw empty key is rejected by prepare_key, but an empty oct JWK is decoded to empty bytes and used directly, so the same key material gets different treatment depending on how it arrived. The class is CWE-347 (improper verification of a cryptographic signature).

With a zero-length key, anyone can compute a valid HMAC for any claims they like. That is why a "trusted" key set matters: the attacker does not need the secret, because there is none.

The lesson is general. Validate key material at every entry point, not at only one of them. The record gives no sign of exploitation in the wild, and the KEV flag is false.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub advisory GHSA-9j54-fg26-wv3r

Last reviewed: 19 October 2026.