Skip to main content

PyJWT CVE-2026-48523

| EUVDEUVD-2026-32918 MEDIUM
Improper Verification of Cryptographic Signature (CWE-347)
2026-05-28 GitHub_M GHSA-jq35-7prp-9v3f PYSEC-2026-176
Authentication Bypass Python Red Hat Jwt Attack Pyjwt Jpadilla
5.4
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
5.4 MEDIUM
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
SUSE
MEDIUM
qualitative
Red Hat
5.4 MEDIUM
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
None

Lifecycle Timeline

2
Patch available
May 28, 2026 - 17:01 EUVD
Analysis Generated
May 28, 2026 - 15:55 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 182 pypi packages depend on pyjwt (134 direct, 49 indirect)

Ecosystem-wide dependent count for version 2.9.0.

DescriptionGitHub Advisory

PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.

AnalysisAI

Algorithm allow-list bypass in PyJWT 2.9.0-2.12.1 permits an attacker who controls a registered JWK/JWKS private key to circumvent caller-enforced algorithm restrictions during JWT signature verification. The library correctly checks the token header's alg claim against the caller-supplied allow-list, but then performs the actual cryptographic verification using the algorithm bound to the PyJWK object rather than the header-declared algorithm - creating a exploitable mismatch. Specifically, the documented PyJWKClient.get_signing_key_from_jwt() flow is affected, meaning applications relying on this pattern for algorithm-restricted JWT validation may accept tokens signed with algorithms they explicitly prohibited. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.

Technical ContextAI

PyJWT (CPE: cpe:2.3:a:jpadilla:pyjwt:*:*:*:*:*:*:*:*) is a widely used Python library for encoding and decoding JSON Web Tokens per RFC 7519. The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature), which covers failures to correctly validate the cryptographic guarantees of a signed artifact. In this case, the flaw is an algorithm substitution or confusion attack: the library splits the algorithm validation step (comparing the JWT header's alg field against the caller's allow-list) from the cryptographic operation step (using the algorithm stored on the PyJWK key object). Because these two steps use different algorithm sources, a token whose header advertises an allowed algorithm but whose key object is bound to a different algorithm can pass both checks independently while bypassing the allow-list restriction entirely. This affects the PyJWKClient.get_signing_key_from_jwt() integration path, which is the documented approach for JWKS-based key resolution.

RemediationAI

Upgrade PyJWT to version 2.13.0, which is the vendor-confirmed fix as detailed in GitHub Security Advisory GHSA-jq35-7prp-9v3f at https://github.com/jpadilla/pyjwt/security/advisories/GHSA-jq35-7prp-9v3f. The fix aligns the algorithm used for signature verification with the caller-supplied allow-list rather than relying solely on the PyJWK object's bound algorithm. As a compensating control if immediate upgrade is not possible, applications can validate that the algorithm declared in the JWT header matches the algorithm bound to the resolved PyJWK object before calling jwt.decode(), and reject tokens where they differ - though this logic must be implemented carefully to avoid introducing new inconsistencies. Alternatively, applications can avoid passing PyJWK objects directly to jwt.decode() and instead extract the raw key material and algorithm explicitly, though this requires changes to the integration pattern. The trade-off of any manual workaround is increased code complexity and ongoing maintenance risk; patching to 2.13.0 is strongly preferred.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
CVE-2026-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

Same weakness CWE-347 – Improper Verification of Cryptographic Signature

View all
CVE-2013-3900 MEDIUM
5.5
CVE-2026-48558 CRITICAL POC
9.5
CVE-2025-59718 CRITICAL
9.8
CVE-2025-47827 MEDIUM POC
4.6
CVE-2025-25291 CRITICAL POC
9.3
CVE-2025-25292 CRITICAL POC
9.3
CVE-2022-25898 CRITICAL POC
9.8
CVE-2024-42004 CRITICAL POC
9.8

Same technique Authentication Bypass

View all
CVE-2023-22515 CRITICAL POC
9.8
CVE-2012-4681 CRITICAL POC
9.8
CVE-2013-2465 CRITICAL POC
9.8
CVE-2011-3544 CRITICAL POC
9.8
CVE-2022-40684 CRITICAL POC
9.8
CVE-2025-61882 CRITICAL POC
9.8
CVE-2024-0012 CRITICAL POC
9.3
CVE-2023-46805 HIGH POC
8.2

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 12 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed
SUSE Linux Enterprise Micro 5.5 Fixed
SUSE Linux Enterprise Module for Basesystem 15 SP7 Fixed

Share

CVE-2026-48523 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy