- NIST's vulnerability database says python-jose through 3.5.0 accepts empty signing secrets. If an application's key resolves to empty, attackers can forge tokens that pass verification.
- The flaw is a missing refusal, not a broken algorithm. Exposure depends on whether any of your systems can end up holding a blank key.
- Ask engineering whether python-jose is in use, which version, and whether any signing key could be empty. Add a startup check that rejects blank secrets.
A festival wristband proves you paid only if the gate staff check it against something real. Imagine the gate staff all use the same public stamp that anyone can copy. Every forged band then looks genuine. That is the flaw NIST's National Vulnerability Database describes in python-jose, a Python library that handles login tokens.
What the record says
The database published CVE-2026-120459 on November 2, 2026. It covers python-jose through version 3.5.0.
The record names two parts of the library, HMACKey and CryptographyHMACKey. Neither one refuses a secret of length zero. The record says unauthenticated attackers can use this to forge JWTs.
There is a condition. The application's verification key for HS256, HS384 or HS512 must resolve to empty. The record gives one example: an oct JWK with an empty k. Under that condition, attackers can forge tokens with arbitrary claims, and jwt.decode accepts them.
How the forgery works
A JWT is a signed digital pass. It carries claims, such as who the user is and what they may do. The server trusts the pass because the signature checks out.
HS256, HS384 and HS512 are signing methods that use one shared secret. The same secret signs the pass and verifies it. Anyone who holds the secret can mint a valid pass.
That is safe only while the secret stays private. An empty secret is known to everyone. An attacker signs a token with a blank key. The library verifies it with a blank key. The two match.
The key file in the record's example is a JSON document, and its secret field is called k. If k is empty, the secret is a value everyone knows, so the signature proves nothing.
Two scores, one precondition
VulnCheck's disclosure address scored the flaw twice. Under CVSS 3.1, it is 7.4, rated High. Under CVSS 4.0, it is 9.1, rated Critical.
Both vectors mark the attack as network-based, needing no privileges and no user action. Both rate the damage to confidentiality and integrity as high and to availability as none.
They differ on difficulty. The 3.1 vector marks attack complexity High. The 4.0 vector marks it Low and adds an attack-requirements flag. The record does not explain the difference.
For a decision-maker, the useful question sits behind the scores. Can any of your systems ever hold an empty key? The record does not say how common that is.
The lesson: a library that trusts its caller
HMAC itself is not broken here. The weakness is a missing refusal. The library assumes the secret is real and never checks. A safe with no combination set would behave the same way: it closes, but anyone can open it.
This shows how small configuration slips become total bypasses. The slip may be minor. The library's silence is what turns it into a way in. Your suppliers' code carries assumptions like this, and your own setup has to satisfy each one.
What to ask your team
Start with an inventory. Which services depend on python-jose, and at what version? The record says the flaw affects versions through 3.5.0. It names no fixed version, so check the project's issue 398 and the VulnCheck advisory. Both are listed as references.
Then ask where signing keys come from. If any HS256, HS384 or HS512 key is loaded from configuration or a key file, could it ever be blank? Engineers can add a startup check that stops the service when a secret is empty.
Finally, ask whether your logs show which tokens were accepted and which key verified them. If something was forged, that record is where you would see it.
A signature is only as strong as the secret behind it. A blank secret protects nothing.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
