CVE-2026-102275 in PyJWT
Summary
by MITRE • 09/29/2026
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.from_jwk in jwt/algorithms.py is affected because private-JWK import path does not compare the public key derived from d with x. This occurs when an OKP private JWK supplies non-corresponding x and d components. As a result, identity derived from x can differ from operations performed with d. Consequently, if an integration also accepts private key parameters from a proof header without rejecting them, an attacker may use a stolen sender-constrained token without the legitimate private key. This issue is fixed in version 2.15.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
PyJWT serves as a widely adopted Python library for implementing JSON Web Token standards, facilitating secure communication between parties by encoding and decoding claims into compact, URL-safe strings. The vulnerability identified within versions ranging from 2.1.0 to 2.15.0 resides specifically in the OKPAlgorithm.from_jwk method located in the jwt/algorithms.py module. This flaw pertains to the handling of Octet Key Pair (OKP) keys defined by RFC 8037, which are commonly used with EdDSA signature algorithms such as Ed25519 and Ed448. The core technical deficiency lies in the private JSON Web Key import path, where the library fails to validate that the public key component x corresponds mathematically to the private key component d. In elliptic curve cryptography, these components are strictly linked; deriving the public point from the private scalar must yield the exact coordinates specified by the public parameter. By omitting this critical consistency check, PyJWT allows for the creation of a cryptographic object where the internal state does not match its declared identity.
The operational impact of this discrepancy is severe in contexts involving sender-constrained tokens or proof-of-possession mechanisms. When an application accepts private key parameters from a proof header without rigorous validation, it relies on the assumption that possession of the private key d proves ownership of the corresponding public identifier x. Due to the vulnerability, an attacker can construct a malicious JWK where the public component x is derived from one valid OKP key pair, while the private component d belongs to a completely different key pair. If PyJWT accepts this mismatched structure without error, subsequent cryptographic operations will use the actual private scalar d for signing or decryption, but identity verification systems may still associate the token with the original public identifier x. This decoupling of identity from operational capability allows an attacker who has stolen a sender-constrained token to replay it using their own private key material that happens to align with the expected public parameters in the validation logic, effectively bypassing authentication controls designed to ensure only the legitimate holder can use the credential.
This vulnerability is classified under CWE-347, which describes Improper Verification of Cryptographic Signature, as well as CWE-295 regarding Improper Certificate Validation, because it undermines the fundamental trust model that binds a key pair together. In terms of MITRE ATT&CK framework mapping, this flaw facilitates techniques related to Credential Access and Defense Evasion, specifically allowing an adversary to masquerade as another user by exploiting weak validation of cryptographic material during token processing. The issue highlights the dangers of trusting input data without performing full structural integrity checks on sensitive security parameters. Developers integrating PyJWT must recognize that partial key imports or relaxed validation modes can introduce significant risks if not accompanied by explicit verification steps.
The recommended mitigation is to upgrade immediately to version 2.15.0, where this consistency check has been implemented and the import path now correctly verifies that the public x coordinate matches the one derived from the private d scalar. For organizations unable to update instantly due to dependency constraints, a temporary workaround involves implementing custom validation logic before passing JWKs into PyJWT algorithms. This external verification should ensure that for any OKP key pair provided, the public point calculated via elliptic curve operations on the private scalar matches the supplied x value exactly. Additionally, applications relying on sender-constrained tokens should avoid accepting raw private key parameters from untrusted sources and instead rely solely on validated public keys or hardware security modules where key material is never exposed in plaintext form to prevent such manipulation opportunities.