PyJWT EUVD-2026-88547

Exploitation requires three specific conditions, not a default-configuration remote hit: (1) the target application uses PyJWT (2.1.0-2.14.0) OKPAlgorithm.from_jwk / PyJWK.from_dict to import OKP (Ed25519/Ed448) private JWKs; (2) the integration accepts full JWK private-key material - specifically the d parameter - from an attacker-controlled source such as a DPoP proof header, without rejecting private components; and (3) the attacker already possesses a stolen sender-constrained (e.g. DPoP-bound) token whose cnf.jkt thumbprint is computed from x. Limiting factors: the attack fails against integrations that only accept public JWKs in proof headers, that reject JWKs containing d, or that verify key consistency; it also requires prior theft of a valid bound token. Standard signature-verification use of PyJWT with trusted server-side keys is NOT affected.

Signals are mixed and point to a real but conditional threat rather than a mass-exploitation emergency. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H, 8.2 High) implies trivial unauthenticated network exploitation, but the description and GHSA advisory make clear this only matters when an integration accepts private-key JWK parameters (d) from an attacker-controlled DPoP proof header AND the attacker already possesses a stolen sender-constrained token - so the practical complexity is higher than AC:L suggests. SSVC agrees it is not a drop-in mass exploit: Exploitation=poc, Automatable=no, Technical Impact=partial. EPSS is very low (0.14%, 3rd percentile) and the CVE is NOT in CISA KEV, consistent with no observed widespread exploitation. A working PoC exists (publicly available exploit code), confirming the key-confusion is real and reproducible, but PoC availability is not active exploitation. Net: this is a genuine authentication/identity-confusion flaw worth prioritizing specifically for services using PyJWT for DPoP or other OKP private-JWK import flows, but it is not an indiscriminate internet-wide risk. Note the conflict to verify: CVSS AC:L understates the real-world precondition (stolen token + permissive integration), so raw 8.2 overstates realistic risk for most deployments.

An attacker who has intercepted a victim's sender-constrained (DPoP) access token crafts an OKP JWK containing the victim's legitimate public key x together with the attacker's own private key d, and submits it in a DPoP proof header. Because PyJWT's OKPAlgorithm.from_jwk never checks that x corresponds to d, it builds the key from the attacker's d while the RFC 7638 thumbprint still matches the victim binding, so the attacker signs a valid proof and replays the stolen token without ever holding the victim's private key. A public PoC demonstrates this end-to-end (stolen_sender_constrained_token_accepted: true).