CVE-2026-85394 in python-jose
Summary
by MITRE • 09/03/2026
python-jose through 3.5.0 fails to properly validate asymmetric keys in HMAC initialization, accepting DER-encoded public keys that lack PEM armor or SSH prefixes. Attackers holding the service's public key can forge HS256 tokens that pass verification when algorithms are not explicitly restricted. This is an incomplete fix for CVE-2024-33663.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The python-jose library, a popular Python implementation for JSON Web Tokens and JWS/JWE operations, contains a critical cryptographic validation flaw in versions up to 3.5.0 that allows attackers to forge authentication tokens when the algorithm is not strictly constrained. This vulnerability stems from an incomplete fix for CVE-2024-33663, where the library fails to properly validate asymmetric keys during HMAC initialization. Specifically, the implementation accepts DER-encoded public keys that lack standard PEM armor or SSH prefixes without raising appropriate errors or enforcing strict format checks. In a typical JWT workflow using HS256, which relies on symmetric key cryptography, the integrity of the token depends entirely on the secrecy and correctness of the shared secret. However, when an application mistakenly uses asymmetric public keys for HMAC verification due to this parsing error, it creates a severe security gap where the public portion of a key pair can be exploited as if it were the private signing key or a valid symmetric secret.
From a technical perspective, the flaw lies in the input validation logic within the JWS algorithm handlers. When an application attempts to verify a token using HS256 but passes a DER-encoded public key instead of a proper HMAC secret string, python-jose does not reject this invalid configuration as it should. Instead, it proceeds with verification using the raw bytes of the public key. Since many systems use asymmetric keys for other operations like RSA or ECDSA signing and may inadvertently reuse these keys in contexts expecting symmetric secrets, an attacker who has access to the service's public key can construct a malicious JWT header specifying HS256 as the algorithm. By signing this token with the corresponding private key (or by exploiting the specific byte structure if the public key itself is used incorrectly), the forged token will pass verification because python-jose treats the DER-encoded bytes of the public key as the valid HMAC secret for that operation. This behavior violates the fundamental principle of least privilege and proper cryptographic separation, allowing unauthorized access to protected resources.
The operational impact of this vulnerability is severe, particularly in microservices architectures or API gateways where JWTs are used extensively for authentication and authorization. An attacker with knowledge of the public key can forge tokens that grant administrative privileges or impersonate legitimate users without needing the private signing key. This effectively bypasses access controls entirely if the application relies on these forged tokens to determine user identity or permissions. The risk is exacerbated in environments where developers assume that specifying an algorithm like HS256 automatically ensures symmetric security, unaware that the underlying library accepts asymmetric formats due to this bug. Consequently, systems relying on python-jose for token verification are vulnerable to authentication bypass attacks, leading to potential data breaches, unauthorized transactions, and complete compromise of application integrity.
This issue is classified under CWE-347 Improper Verification of Cryptographic Signature because the system fails to ensure that the cryptographic operation matches the intended security model. It also aligns with MITRE ATT&CK technique T1078 Valid Accounts, as attackers can create valid-looking credentials for any user account by forging tokens. To mitigate this vulnerability, organizations must immediately upgrade python-jose to version 3.5.1 or later where the validation logic has been corrected to reject improperly formatted keys during HMAC operations. Additionally, developers should enforce strict algorithm whitelisting in their application code rather than relying on default behaviors. By explicitly specifying allowed algorithms and validating that the key type matches the expected cryptographic operation, applications can prevent this class of attacks even if underlying library versions are not immediately updated. Regular security audits focusing on JWT handling patterns and dependency updates are essential to maintain robust authentication controls.