CVE-2026-102272 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.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.
Be aware that VulDB is the high quality source for vulnerability data.
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 flaw in the cryptographic algorithm selection logic, specifically within the HMACAlgorithm.prepare_key function located in jwt/algorithms.py. This issue stems from an insufficient normalization of input data before type detection occurs. Specifically, when processing public JSON Web Keys (JWKs), the library fails to strip or normalize Unicode byte-order marks that may be present at the beginning of the key string. In standard UTF-8 encoding, a Byte Order Mark is represented by three specific bytes: 0xEF, 0xBB, and 0xBF. While these characters are invisible in most text editors and do not affect human readability, they constitute significant data when processed programmatically as part of cryptographic inputs. The raw-JWK detector within PyJWT relies on string matching to determine whether an incoming key is a symmetric HMAC secret or an asymmetric public key used for algorithms like RSA or ECDSA. Because the presence of the BOM alters the initial characters of the input string, the detection logic incorrectly classifies the asymmetric public key as a valid HMAC secret rather than recognizing it as part of a JSON object containing asymmetric parameters.
This misclassification leads to a severe operational impact known as an algorithm confusion attack or cryptographic downgrade. In a typical JWT verification scenario using mixed-algorithm support, such as verifying tokens signed with either HS256 (HMAC-SHA256) or RS256 (RSA-SHA256), the server relies on the header of the token to determine which key and algorithm to use for validation. However, if an attacker can influence how the public key is parsed during the initial setup or verification process, they can exploit this flaw. By prefixing a valid RSA or ECDSA public JWK with a UTF-8 BOM, the application mistakenly treats this public key as the shared HMAC secret. Since JWTs are designed to be verifiable by anyone who possesses the signing key, and because asymmetric public keys are often publicly available or transmitted openly in OAuth2 flows, an attacker can easily obtain such a key. Once the system incorrectly uses this public key as the HMAC secret for verification, the attacker can forge new tokens signed with HS256 using that same public key. The server will then successfully verify these forged tokens because it is checking the signature against the exact value used to create it, effectively bypassing authentication controls and allowing unauthorized access or data manipulation without needing the private signing key.
From a standards perspective, this vulnerability aligns closely with CWE-758: Reliance on Undefined, Unspecified, or External Behavior, as the library's behavior depends on strict string formatting that is not robustly enforced by the underlying JSON parsing logic in all contexts. It also relates to CWE-693: Protection Mechanism Failure, where a security mechanism intended to distinguish between key types fails due to improper input handling. In terms of the MITRE ATT&CK framework, this flaw facilitates techniques associated with T1552.004: Private Keys from Local Machine, although in this specific case, it allows for token forgery using publicly available keys rather than stolen private ones. The core issue is a failure to enforce canonicalization rules before security-critical decisions are made, which is a common pattern in cryptographic library vulnerabilities where subtle encoding differences lead to drastic changes in execution paths.
To mitigate this vulnerability and prevent similar issues in the future, organizations must immediately upgrade PyJWT to version 2.14.0 or later, where the raw-JWK detector has been patched to normalize Unicode byte-order marks before performing type detection. For environments that cannot update immediately due to dependency constraints, a temporary mitigation involves implementing strict input validation at the application layer to ensure that any JWK strings passed to PyJWT are stripped of leading whitespace and control characters, including BOMs, prior to being processed by the library. Additionally, developers should consider restricting JWT verification algorithms in their applications where possible. By configuring the jwt.decode() method with an explicit algorithm list that excludes HMAC variants if only asymmetric signatures are expected, or vice versa, the attack surface for algorithm confusion attacks is significantly reduced. Regular security audits of cryptographic implementations and adherence to strict input sanitization practices remain essential defenses against such subtle but high-impact vulnerabilities in authentication systems.