CVE-2026-120459 in python-jose
Summary
by MITRE • 11/02/2026
python-jose through 3.5.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge JWTs because HMACKey and CryptographyHMACKey accept zero-length HMAC secrets. When an application's HS256/HS384/HS512 verification key resolves to empty, such as an oct JWK with empty k, attackers can forge tokens with arbitrary claims that jwt.decode accepts.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The python-jose library, specifically versions up through 3.5.0, contains a critical authentication bypass vulnerability rooted in the improper validation of cryptographic keys during JSON Web Token verification processes. This flaw affects implementations utilizing HMAC-based signing algorithms such as HS256, HS384, and HS512. The core technical deficiency lies within the internal key handling mechanisms, specifically affecting classes like HMACKey and CryptographyHMACKey. These components are designed to validate that a provided secret is suitable for cryptographic operations but fail to enforce non-empty requirements for the HMAC secret material. Consequently, if an application resolves its verification key from an octet type JSON Web Key with an empty k parameter or otherwise provides a zero-length string as the shared secret, the library proceeds with token validation without raising an exception or rejecting the input. This behavior deviates from secure cryptographic practices which mandate that symmetric keys must possess sufficient entropy and length to prevent trivial forgery attacks.
The operational impact of this vulnerability is severe, enabling unauthenticated attackers to forge valid JSON Web Tokens with arbitrary claims. Since jwt.decode accepts tokens signed with empty secrets without error, an attacker can generate a token using any HMAC implementation configured with an empty key string. The resulting signature will be mathematically valid according to the library's flawed verification logic. When this forged token is presented to an application relying on python-jose for authentication or authorization decisions, the system incorrectly validates it as authentic. This allows attackers to impersonate other users, escalate privileges by injecting administrative claims into their tokens, or bypass access controls entirely. The vulnerability effectively neutralizes the integrity guarantees provided by HMAC-based JWTs when misconfigured with empty secrets, turning a security control into an open door for unauthorized access.
This issue aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity from the Common Weakness Enumeration taxonomy. The failure to validate that cryptographic inputs meet minimum complexity or length requirements is a classic instance of weak input validation leading to authentication bypass. In terms of attack patterns, this vulnerability facilitates techniques associated with MITRE ATT&CK T1078 Valid Accounts and potentially T1556 Modification of Authentication Process if the forged tokens are used to alter session states. The root cause stems from a lack of defensive programming practices where developers assume that key material provided by configuration or external sources is always valid, without implementing explicit checks for empty strings or null values before passing them to cryptographic functions.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Organizations using python-jose should immediately upgrade to version 3.5.1 or later where this validation logic has been corrected to reject zero-length secrets during token verification. For applications unable to update the library promptly, developers can implement a custom key resolver that explicitly checks for empty strings before returning keys to the jwt.decode function. This wrapper layer acts as a defensive barrier ensuring no empty secret is ever passed to the underlying cryptographic operations. Furthermore, security teams should audit their JWT implementation patterns to ensure that HMAC secrets are generated using cryptographically secure random number generators and adhere to minimum length requirements defined by industry standards such as NIST SP 800-132 for key derivation and strength. Regular code reviews focusing on authentication flows can help identify similar vulnerabilities where implicit trust in configuration data leads to security failures.