CVE-2026-102268.

Disclosure summary

**Prerequisites** (both conditions must hold; both are deployment properties, not attacker-controlled at request time): - The `jwt.decode` allow-list mixes an HMAC algorithm with an asymmetric one, e.g. `algorithms=["ES256", "HS256"]` (the RFC 8725 footgun the guard exists to backstop). - The verification key is passed as raw PEM text/bytes on the non-`PyJWK` path, in a byte-form that `cryptography`'s loader accepts but PyJWT's `is_pem_format` regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling. The attacker additionally needs the public verification key, which is public by definition, and `cryptography` must be installed. The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when `is_pem_format()` recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This

Source-specific records & product guidance

Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.

Original records & references

• NIST NVD record
• CVE Program record
• github.com — Reviewed advisory

PUBLISHED 2026-09-29T19:17:33-04:00
MODIFIED 2026-09-29T19:17:34-04:00
INGESTED 2026-10-06T11:43:08-04:00