CVE-2026-102266: high-severity vulnerability in jpadilla pyjwt
PyJWK accepts empty HMAC keys, bypassing PyJWT's empty-key validation
Published · Updated
21Vexday Risk Score
No sign of exploitation. No public exploitation artifact known so far.
ssvc Trackcvss 7.4epss 0.2%
exploitation probability
0.2%top 94% of all CVEs
observed exploitation
nono source reports it
PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.from_jwk is affected because PyJWK verification path used the decoded key without applying prepare_key validation. This occurs when a trusted JWK Set contains an oct entry with an empty k value. As a result, an attacker signs an HMAC token with the same zero-length key accepted by PyJWT. Consequently, forged token can carry arbitrary authenticated claims. This issue is fixed in version 2.14.0.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Affected products
jpadilla · pyjwtRelated CVEs — jpadilla pyjwt
In the same product, most dangerous first.
CVE-2022-29217HIGHKey confusion through non-blocklisted public key formats in PyJWTEPSS 1.4%CVE-2024-53861LOWIssuer field partial matches allowed in pyjwtEPSS 0.8%CVE-2026-48526HIGHPyJWT: Public-key JWK accepted as HMAC secret enables forged HS256 tokens when mixed families are allowedEPSS 0.4%CVE-2026-48525MEDIUMPyJWT: Unauthenticated DoS via unbounded Base64URL decoding of unused payload segment in b64=false detached JWSEPSS 0.4%CVE-2026-102274MEDIUMPyJWT: Malformed RSA JWK aborts parsing of an entire JWK SetEPSS 0.4%CVE-2026-101917MEDIUMPyJWT: PyJWKClient still amplifies unauthenticated JWKS fetches on unknown kid values (incomplete fix of CVE-2026-48524)EPSS 0.4%