CVE-2026-102266 in PyJWT
Summary
by MITRE • 09/29/2026
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. 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 in PyJWT versions from 2.13.0 through 2.14.0 represents a critical authentication bypass flaw rooted in the improper handling of JSON Web Key (JWK) inputs during HMAC signature verification. PyJWT is widely utilized for implementing JSON Web Token standards, which are essential for securely transmitting claims between parties as a JSON object. The core issue resides within the HMACAlgorithm.from_jwk method, specifically in the path that processes JWK sets containing octet sequence keys. When an attacker provides a trusted JWK Set with an oct entry where the key value (k parameter) is empty or zero-length, the library fails to apply necessary validation steps before using the decoded key for cryptographic operations. This oversight allows the system to accept and utilize a null byte string as a valid signing secret, effectively bypassing the intended security controls that rely on non-empty secrets for HMAC integrity checks.
From a technical perspective, this flaw aligns with CWE-287, which describes Improper Authentication, specifically falling under scenarios where authentication mechanisms fail due to weak or missing credentials. The vulnerability exploits the fact that many cryptographic libraries and protocols may technically accept empty keys if not explicitly guarded against by application-level validation logic within the library itself. By signing an HMAC token using this zero-length key, an attacker can generate a valid signature that PyJWT will verify as authentic because it uses the same empty string for verification. This results in CWE-345, Insufficient Verification of Data Authenticity, as the system fails to ensure that the data has been generated by someone possessing a proper secret key rather than just any arbitrary input. The operational impact is severe, allowing an attacker to forge tokens with arbitrary authenticated claims. These forged tokens can be used to impersonate legitimate users, escalate privileges within an application, or access protected resources without authorization, effectively compromising the integrity and confidentiality of the authentication system.
This vulnerability also maps to MITRE ATT&CK technique T1649, Steal Application Access Token, as it enables the creation of valid tokens that can be used for unauthorized access. Furthermore, it relates to CWE-757, Selection of Less-Secure Algorithm During Negotiation, in a broader sense where the implementation fails to enforce security constraints during key processing. The lack of validation on the k parameter allows an attacker to manipulate the cryptographic context by forcing the use of a trivially guessable or empty secret. This undermines the fundamental assumption that HMAC signatures provide integrity and authenticity guarantees based on shared secrets. In production environments relying on PyJWT for session management, API authentication, or single sign-on implementations, this flaw could lead to widespread unauthorized access if JWK sets are dynamically fetched from external sources without rigorous validation of their contents.
Mitigation strategies primarily involve upgrading to version 2.14.0 or later, where the developers have addressed this issue by implementing proper validation for key parameters within the HMAC verification path. For organizations unable to immediately upgrade, defensive coding practices should be employed to validate JWK inputs before passing them to PyJWT libraries. This includes ensuring that any oct entry in a JWK Set has a non-empty k value and verifying that keys meet minimum entropy requirements. Additionally, implementing strict allowlists for trusted issuers and validating token claims against expected values can provide an additional layer of defense. Security teams should also monitor for anomalies in authentication logs indicative of forged tokens being accepted by the system. Regular audits of third-party dependencies and their configuration settings are essential to prevent similar vulnerabilities arising from improper handling of cryptographic materials.