PyJWT is affected by 12 vulnerabilities involving JWKS fetching, SSRF, JWT algorithm-confusion protections, JWK parsing, authentication bypass, and denial-of-service conditions. The advisories include one Critical, six High, and five Medium-severity vulnerabilities. The supplied advisory document lists PyJWT 2.14.0 as the patched release for the vulnerabilities where a fix is specified.
CVE-2026-48524 (CVSS 3.7 – Low): PyJWKClient performs unbounded JWKS endpoint requests for attacker-controlled unknown kid values. Repeated invalid tokens can force fresh JWKS requests, causing network I/O exhaustion and potentially disrupting authentication availability. Affected PyJWT 2.0.0–2.12.1; fixed 2.13.0.
CVE-2026-48522 (CVSS 4.2 – Medium): PyJWKClient lacks a URL scheme allowlist and can process file://, ftp://, and data: schemes. In affected application configurations, this can enable local file access through JWKS retrieval and potentially JWT forgery. Affected through 2.12.1; fixed 2.13.0.
CVE-2026-102274 (CVSS 5.9 – Medium): A malformed RSA JWK can raise an uncaught ValueError while parsing a JWK Set, aborting processing of the entire set and preventing valid keys from being loaded, resulting in an availability impact. Affected 2.9.0–2.13.0; fixed 2.14.0.
CVE-2026-101917 (CVSS 5.3 – Medium): PyJWKClient continues to force a fresh JWKS request for every unknown kid, allowing unauthenticated attackers to amplify outbound requests and consume application and JWKS-provider resources. Fixed in 2.14.0.
CVE-2026-102272 (CVSS 7.4 – High): A UTF-8 BOM can bypass PyJWT's asymmetric-key detection when public JWK material is used as an HMAC secret, allowing forged JWTs in applications configured with both symmetric and asymmetric algorithms. Fixed in 2.14.0.
CVE-2026-102271 (CVSS 7.4 – High): DER-encoded RSA or EC public keys are not recognized by PyJWT's asymmetric-key protection and can be accepted as HMAC secrets. In mixed-algorithm configurations, attackers who know the public key can forge JWTs with arbitrary claims. Fixed in 2.14.0.
CVE-2026-102267 (CVSS 7.4 – High): PyJWKClient follows HTTP redirects without validating the redirected destination. An attacker who can influence the trusted JWKS endpoint's response may redirect requests to another host, potentially exposing forwarded headers or substituting JWKS key material. Fixed in 2.14.0.
CVE-2026-102273 (CVSS 7.4 – High): Public RSA, EC, or OKP JWK material can be accepted as an HMAC secret when wrapped in certain JWK/JWKS container formats. Applications mixing symmetric and asymmetric algorithms may therefore accept attacker-forged JWT claims. Fixed in 2.14.0.
CVE-2026-102268 (CVSS 9.1 – Critical): Whitespace-, line-ending-, or formatting-mutated PEM public keys can bypass PyJWT's asymmetric-key detection while remaining valid to the cryptographic loader. In mixed HS*/asymmetric configurations, attackers can use the public key as an HMAC secret to forge JWTs. Fixed in 2.14.0.
CVE-2026-102269 (CVSS 4.8 – Medium): PyJWT accepts non-canonical Base64URL characters in the JWS signature segment, allowing different serialized tokens to decode to the same signature bytes. Applications relying on raw-token string matching for revocation may therefore fail to recognize a modified representation of a revoked token. Fixed in 2.14.0.
CVE-2026-102265 (CVSS 5.3 – Medium): A deeply nested JWT header can trigger an uncaught RecursionError during JSON parsing, causing an unauthenticated malformed token to generate a request-level failure or HTTP 500 response. Fixed in 2.14.0.
CVE-2026-102266 (CVSS 7.4 – High): PyJWK accepts an empty HMAC oct key and bypasses the normal empty-key validation. If an application trusts an empty symmetric JWK, an attacker can generate HS256 tokens using the zero-length key and forge arbitrary authenticated claims. Fixed in 2.14.0.[/subscribe_to_unlock_form]
PyJWT is affected by 12 vulnerabilities involving JWKS fetching, SSRF, JWT algorithm-confusion protections, JWK parsing, authentication bypass, and denial-of-service conditions. The advisories include one Critical, six High, and five Medium-severity vulnerabilities. The supplied advisory document lists PyJWT 2.14.0 as the patched release for the vulnerabilities where a fix is specified.
CVE-2026-48524 (CVSS 3.7 – Low): PyJWKClient performs unbounded JWKS endpoint requests for attacker-controlled unknown kid values. Repeated invalid tokens can force fresh JWKS requests, causing network I/O exhaustion and potentially disrupting authentication availability. Affected PyJWT 2.0.0–2.12.1; fixed 2.13.0.
CVE-2026-48522 (CVSS 4.2 – Medium): PyJWKClient lacks a URL scheme allowlist and can process file://, ftp://, and data: schemes. In affected application configurations, this can enable local file access through JWKS retrieval and potentially JWT forgery. Affected through 2.12.1; fixed 2.13.0.
CVE-2026-102274 (CVSS 5.9 – Medium): A malformed RSA JWK can raise an uncaught ValueError while parsing a JWK Set, aborting processing of the entire set and preventing valid keys from being loaded, resulting in an availability impact. Affected 2.9.0–2.13.0; fixed 2.14.0.
CVE-2026-101917 (CVSS 5.3 – Medium): PyJWKClient continues to force a fresh JWKS request for every unknown kid, allowing unauthenticated attackers to amplify outbound requests and consume application and JWKS-provider resources. Fixed in 2.14.0.
CVE-2026-102272 (CVSS 7.4 – High): A UTF-8 BOM can bypass PyJWT's asymmetric-key detection when public JWK material is used as an HMAC secret, allowing forged JWTs in applications configured with both symmetric and asymmetric algorithms. Fixed in 2.14.0.
CVE-2026-102271 (CVSS 7.4 – High): DER-encoded RSA or EC public keys are not recognized by PyJWT's asymmetric-key protection and can be accepted as HMAC secrets. In mixed-algorithm configurations, attackers who know the public key can forge JWTs with arbitrary claims. Fixed in 2.14.0.
CVE-2026-102267 (CVSS 7.4 – High): PyJWKClient follows HTTP redirects without validating the redirected destination. An attacker who can influence the trusted JWKS endpoint's response may redirect requests to another host, potentially exposing forwarded headers or substituting JWKS key material. Fixed in 2.14.0.
CVE-2026-102273 (CVSS 7.4 – High): Public RSA, EC, or OKP JWK material can be accepted as an HMAC secret when wrapped in certain JWK/JWKS container formats. Applications mixing symmetric and asymmetric algorithms may therefore accept attacker-forged JWT claims. Fixed in 2.14.0.
CVE-2026-102268 (CVSS 9.1 – Critical): Whitespace-, line-ending-, or formatting-mutated PEM public keys can bypass PyJWT's asymmetric-key detection while remaining valid to the cryptographic loader. In mixed HS*/asymmetric configurations, attackers can use the public key as an HMAC secret to forge JWTs. Fixed in 2.14.0.
CVE-2026-102269 (CVSS 4.8 – Medium): PyJWT accepts non-canonical Base64URL characters in the JWS signature segment, allowing different serialized tokens to decode to the same signature bytes. Applications relying on raw-token string matching for revocation may therefore fail to recognize a modified representation of a revoked token. Fixed in 2.14.0.
CVE-2026-102265 (CVSS 5.3 – Medium): A deeply nested JWT header can trigger an uncaught RecursionError during JSON parsing, causing an unauthenticated malformed token to generate a request-level failure or HTTP 500 response. Fixed in 2.14.0.
CVE-2026-102266 (CVSS 7.4 – High): PyJWK accepts an empty HMAC oct key and bypasses the normal empty-key validation. If an application trusts an empty symmetric JWK, an attacker can generate HS256 tokens using the zero-length key and forge arbitrary authenticated claims. Fixed in 2.14.0.[emaillocker id="1283"]
Overall, the most significant issues are the algorithm-confusion vulnerabilities that can enable JWT authentication or authorization bypass under specific application configurations, particularly CVE-2026-102268, along with the empty-HMAC-key issue and other public-key handling flaws.
We recommend you to update PyJWT to version 2.14.0 or 2.14.0.
The following reports contain further technical details:
[/emaillocker]