CVE-2026-102271 in PyJWT
Summary
by MITRE • 09/29/2026
PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within PyJWT versions ranging from 2.4.0 to 2.14.0 represents a critical implementation flaw in how cryptographic keys are processed during the verification of JSON Web Tokens. PyJWT is widely used for implementing stateless authentication and authorization mechanisms by encoding claims into signed tokens using standards such as HMAC-SHA256 or RSA-based algorithms. The core issue resides specifically within the HMACAlgorithm.prepare_key method, which serves as a gatekeeper to ensure that keys provided for asymmetric verification are handled correctly when they might be misinterpreted as symmetric secrets. This flaw arises from an overly simplistic validation mechanism that relies on textual markers to distinguish between different key formats rather than performing rigorous structural analysis of the cryptographic material itself.
The technical root cause is tied to how Python libraries typically handle PEM-encoded keys versus DER-encoded binary data. In many implementations, a check for specific string literals such as BEGIN PUBLIC KEY or -----BEGIN RSA PUBLIC KEY----- is used to confirm that a provided key is indeed an asymmetric public key and not a symmetric secret. However, this textual guard fails when the input key is in Distinguished Encoding Rules format, which is a binary ASN.1 structure devoid of human-readable headers or footers. When an application mixes HMAC verification with asymmetric algorithms and supplies a DER-encoded public key as the shared verification key for an HMAC operation, PyJWT does not detect that this is a public key intended for asymmetric use. Instead, it proceeds to treat the raw bytes of the DER encoding directly as the secret key material for the HMAC computation.
This misinterpretation leads to a severe security consequence known as token forgery via cryptographic confusion. Since the attacker typically has access to the victim's public key through standard channels such as API documentation or certificate transparency logs, they can obtain the exact byte sequence that PyJWT will mistakenly use as an HMAC secret. With knowledge of this derived secret, an attacker can compute valid HMAC signatures for arbitrary payloads without possessing any private keys. This allows them to forge authenticated tokens that appear legitimate to the server, effectively bypassing authentication controls and gaining unauthorized access to protected resources or performing actions on behalf of other users.
From a classification perspective, this vulnerability aligns with CWE-327 Use of a Broken or Risky Cryptographic Algorithm, specifically regarding the misuse of cryptographic primitives due to improper key handling. It also reflects aspects of CWE-940 Improper Verification of Key Type, where the system fails to correctly identify and validate the type of cryptographic material before processing it. In terms of offensive security frameworks like MITRE ATT&CK, this flaw facilitates techniques related to Token Manipulation, allowing adversaries to create forged tokens for initial access or privilege escalation by exploiting weak key validation logic in authentication systems.
The operational impact is significant because many enterprise applications rely on PyJWT for securing microservices and API endpoints. If a developer inadvertently configures an endpoint to accept both HMAC-signed tokens and asymmetrically signed tokens using the same verification routine, or if they pass a public key into a function expecting a symmetric secret without proper type checking, the system becomes vulnerable. The attack does not require complex exploitation chains; it relies solely on the attacker knowing the public key and understanding that the library will misuse its binary representation as a shared secret. This undermines the fundamental security guarantee of JWTs, which is integrity verification through secure cryptographic signing.
To mitigate this vulnerability, organizations must upgrade PyJWT to version 2.14.0 or later, where the prepare_key method has been hardened to properly handle DER-encoded keys and prevent their misuse as HMAC secrets. Developers should also review application code for any instances where public keys are passed into functions that expect symmetric shared secrets, ensuring strict type checking is implemented at the application layer regardless of library updates. Additionally, adhering to the principle of least privilege in cryptographic operations involves clearly separating asymmetric verification logic from symmetric signing logic to prevent cross-protocol confusion attacks. Regular security audits and static code analysis tools configured to detect improper key usage patterns can further reduce the risk of such implementation errors in production environments.