Advisory · CVE-2026-120459
python-jose accepts empty HMAC keys, enabling JWT forgery
python-jose through 3.5.0 accepts zero-length HMAC secrets, so an application whose HS256, HS384, or HS512 verification key resolves to empty lets unauthenticated attackers forge JWTs.
- Vendor
- mpdavis
- Product
- python-jose
- Identifier / CWE
- CVE-2026-120459
CWE-347 - Action timing
- Immediate
Explain it like I’m five
A JWT is a stamped pass, and the stamp is made with a secret key. If the secret key is blank, anyone can make the same stamp, because a blank stamp is the same for everybody.
- 01Empty key configuration
An application verification key for HS256, HS384, or HS512 resolves to an empty value, such as an oct JWK with an empty k field.
- 02No rejection
python-jose HMACKey and CryptographyHMACKey accept the zero-length secret instead of rejecting it.
- 03Forged token signed
An unauthenticated attacker signs a JWT with the empty key and arbitrary claims.
- 04Token accepted
jwt.decode accepts the forged token, granting whatever identity the claims assert.
What happened
python-jose through 3.5.0 contains an authentication bypass vulnerability because HMACKey and CryptographyHMACKey accept zero-length HMAC secrets. When an application’s HS256, HS384, or HS512 verification key resolves to empty, such as an oct JWK with an empty k value, attackers can forge tokens with arbitrary claims that jwt.decode accepts. The record rates it critical at CVSS 9.1 under version 4.0, and high at 7.4 under version 3.1.
No fixed release is stated in the NVD record or the sources checked for this run, so this advisory claims none, and the latest release listed for the project is 3.5.0. The precondition matters: only applications whose key actually resolves to empty are exposed, which makes this a configuration audit as much as a library flaw. Any deployment that can reach that state has no effective authentication at all.
What to do
- Inventory applications using python-jose for JWT verification and identify every HS256, HS384, and HS512 key source.
- Fail closed on empty, missing, or unresolved keys: reject them at startup and at verification time, and never fall back to an empty default.
- Audit key loading paths, including JWK sets and environment-derived secrets, for values that can resolve to an empty string or empty bytes.
- Review authentication logs for tokens whose claims do not match any issued session, and rotate credentials and sessions if forgery cannot be excluded.
- Track the project issue and upgrade to a patched release as soon as the vendor publishes one.
Management note
An empty secret is not a weak secret, it is no secret. Treat any service that can verify tokens against a blank key as unauthenticated until the key-loading path is proven to reject empty values, patched library or not.