python-jose CVE-2026-120459

Exploitation requires that the application's HS256/HS384/HS512 verification key actually resolves to an empty/zero-length HMAC secret - for example an oct JWK with an empty 'k' value, or an HMACKey/CryptographyHMACKey constructed from a zero-length secret. This is the AT:P (Attack Requirements: Present) condition in the CVSS 4.0 vector: against such a deployment, a remote unauthenticated attacker (PR:N) can forge tokens with arbitrary claims that jwt.decode accepts. The principal limiting factor is that correctly configured deployments supplying a non-empty, properly sourced HMAC secret are not exploitable; the flaw depends on a key-resolution/misconfiguration path yielding an empty key rather than on any default network-facing behavior.

Signals are moderately strong but not uniform. The CVSS 4.0 base score of 9.1 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) and the vuln.today 'act_now' decision label, combined with reporting by VulnCheck, argue for prompt remediation. However, the vector itself tempers raw severity: AT:P (Attack Requirements: Present) encodes the fact that exploitation is conditional - the application's HMAC verification key must actually resolve to an empty/zero-length value, which is not the case for correctly configured deployments. No CISA KEV listing is present in the input, so this is not confirmed as actively exploited; per available data, no public exploit code is identified (the references are a bug-tracker issue, two source files, and the VulnCheck advisory, none flagged as working PoC/exploit code). No EPSS score was supplied, so widespread-exploitation probability cannot be quantified here. Net: this is a genuine authentication-bypass priority for any deployment whose HS256/HS384/HS512 key can resolve to empty (the signature check is effectively void against a known/empty secret, allowing forged tokens), but the AT:P precondition means it is not an unconditional network-unauthenticated compromise of every default install. Note the input provides only a CVSS 4.0 vector - no 3.1 vector - so 3.1-based tooling comparisons require the independently assessed vector below.

An application validates incoming JWTs with python-jose using an HS256 key sourced from an oct JWK whose 'k' value is empty (or otherwise resolves to a zero-length secret). A remote, unauthenticated attacker crafts a JWT with arbitrary claims (e.g., elevated roles or another user's identity), HMAC-signs it with the empty key, and submits it; jwt.decode accepts the forged token, bypassing authentication. No public working exploit is identified in the provided data, and the attack only succeeds where the verification key actually resolves to empty.