CVE-2026-102275: PyJWT accepts inconsistent OKP x/d JWKs, causing public/private key identity confusion
PyJWT is a Python implementation of JSON Web Token standards. From 2.1.0 until 2.15.0, PyJWT OKPAlgorithm.fromjwk 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PyJWTto a version that resolves this vulnerability.Fixed in 2.15.0
Event History
Frequently Asked Questions
Which deployments are most likely to be exposed?
The relevant exposure is in integrations using sender-constrained tokens that accept private-key parameters from a proof header without rejecting them. PyJWT versions from 2.1.0 until the 2.15.0 fix are identified as affected.
What does an attacker need to exploit this?
An attacker needs a stolen sender-constrained token and an integration that accepts the relevant private key parameters in the proof header. The issue can allow use of that token without possession of the legitimate private key.
What can be done before updating?
Ensure the integration rejects private key parameters supplied in proof headers. This prevents the private-JWK import path described from being used in the affected scenario.
How can we assess whether our integration is at risk?
Review uses of PyJWT OKP JWK import, particularly flows that process JWKs containing both x and d values. Determine whether the application accepts such private key material from proof headers and uses sender-constrained tokens.