PyJWT CVE-2026-102269

Requires the application to use PyJWT < 2.14.0 AND to enforce token revocation/blocklisting by matching the raw, serialized token string rather than a claim such as jti. The attacker must already possess a valid-but-revoked (or otherwise blocklisted) token whose signature still verifies. Exploitation is LIMITED by this non-default architecture (PyJWT does not itself provide revocation), which drives CVSS AC:H; applications that revoke by claim/identifier, use short-lived tokens without a blocklist, or perform no raw-token comparison are unaffected. No user interaction or privileges are needed beyond holding the target token.

This is a real but low-severity defense-in-depth flaw, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, base 4.8) is internally consistent with the described impact: network-reachable, no privileges, but high complexity because exploitation depends on a specific application architecture (raw-token/string-based JWT revocation or blocklisting) rather than PyJWT defaults. The core impact is an integrity/access-control failure - a revoked or blocklisted token can be reissued in a non-canonical serialization that still verifies but evades string-match revocation - so I lean toward C:N/I:L rather than the vendor's C:L/I:L. There is no EPSS score, no CISA KEV listing, and no standalone public exploit (the fix commit ships only a unit test), so exploitation status is 'no public exploit identified at time of analysis.' Signals do not conflict; they converge on a genuinely narrow-trigger issue in an extremely widely-used library. Note the vendor 'Information Disclosure' tag is misleading - the mechanism is signature-segment malleability leading to revocation bypass (integrity), not data leakage.

An attacker holds a JWT that has been revoked or added to a blocklist (e.g., after logout or credential compromise), where the application enforces revocation by matching the raw token string. The attacker appends non-Base64URL characters to the compact JWS signature segment; because PyJWT < 2.14.0 decodes it to the identical signature bytes, the modified token still passes signature verification while its serialized form no longer matches the blocklist entry, restoring access. No public exploit code is published, and CVSS complexity is High because it only works against applications using raw-token revocation.