CVE-2026-102273 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, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified within PyJWT versions ranging from 2.13.0 to 2.14.0 represents a critical flaw in the cryptographic key handling logic, specifically affecting the HMACAlgorithm.prepare_key method. This issue stems from an incomplete validation mechanism that fails to properly distinguish between different formats of JSON Web Key (JWK) representations. In secure applications, it is common for systems to support both symmetric algorithms like HMAC and asymmetric algorithms such as RSA or ECDSA. To facilitate this flexibility, developers often pass key material in various forms, including raw bytes or structured JWK containers. The flaw arises because the internal guard designed to validate HMAC keys only recognizes top-level public JWK objects but fails to account for container representations that wrap these keys. This oversight creates a scenario where the library incorrectly accepts asymmetric public key material as valid input for symmetric HMAC operations.
From a technical perspective, this misclassification allows an attacker who possesses knowledge of the application's public key to forge JSON Web Tokens with arbitrary authenticated claims. In standard JWT usage, the integrity and authenticity of tokens are guaranteed by signing them with a secret known only to the issuer and verifier in the case of HMAC, or using private keys for asymmetric signatures. When PyJWT erroneously treats a public JWK as an HMAC secret, it effectively exposes the symmetric key material used for verification. Since public keys are often transmitted openly or stored in well-known locations such as JWKS endpoints, this exposure is trivial for any adversary with network access to the service. The attacker can then use this exposed key to generate valid signatures for malicious tokens, bypassing authentication and authorization controls entirely.
The operational impact of this vulnerability is severe, potentially leading to complete compromise of application security mechanisms that rely on JWTs for session management or API authentication. An authenticated attack could allow an adversary to impersonate any user, escalate privileges by forging administrative claims, or manipulate data integrity checks within the system. This aligns with CWE-327, which describes the use of a broken or risky cryptographic algorithm, and specifically relates to improper key validation that leads to information disclosure and subsequent authentication bypass. Furthermore, this exploitation technique maps directly to MITRE ATT&CK techniques related to Token Manipulation, where adversaries create false tokens to gain unauthorized access to resources without needing to exploit additional vulnerabilities in the application logic itself.
Mitigation for this issue requires an immediate upgrade of the PyJWT library to version 2.14.0 or later, which contains the corrected key validation logic that properly handles container representations and prevents asymmetric keys from being used as HMAC secrets. For applications unable to update immediately due to dependency constraints, a temporary workaround involves strictly validating the type and structure of any key material passed to JWT verification functions before invocation. Developers should ensure that public keys are never passed directly into methods expecting symmetric secrets and instead implement explicit checks to reject JWK containers when an HMAC algorithm is specified. Additionally, implementing strict allow-lists for supported algorithms during token verification can further reduce the attack surface by preventing the interpreter from attempting to process unexpected key formats altogether.