Skip to main content

PyJWT EUVDEUVD-2026-32918

| CVE-2026-48523 MEDIUM
Improper Verification of Cryptographic Signature (CWE-347)
2026-05-28 GitHub_M GHSA-jq35-7prp-9v3f PYSEC-2026-176
Authentication Bypass Jwt Attack Python Red Hat
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

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
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 Jwt Attack

View all
CVE-2013-3900 MEDIUM
5.5 Dec 11

Why is Microsoft republishing a CVE from 2013? We are republishing CVE-2013-3900 in the Security Update Guide to update

CVE-2026-48558 CRITICAL POC
9.5 Jun 12

Authentication bypass in SimpleHelp 5.5.15 and prior (plus 6.0 pre-release builds) allows remote unauthenticated attacke
CVE-2025-59718 CRITICAL
9.8 Dec 09

Authentication bypass in Fortinet FortiOS, FortiProxy, and FortiSwitchManager allows unauthenticated remote attackers to
CVE-2025-25291 CRITICAL POC
9.3 Mar 12

ruby-saml provides security assertion markup language (SAML) single sign-on (SSO) for Ruby. Rated critical severity (CVS
CVE-2025-25292 CRITICAL POC
9.3 Mar 12

ruby-saml provides security assertion markup language (SAML) single sign-on (SSO) for Ruby. Rated critical severity (CVS
CVE-2022-25898 CRITICAL POC
9.8 Jul 01

The package jsrsasign before 10.5.25 are vulnerable to Improper Verification of Cryptographic Signature when JWS or JWT

CVE-2024-42004 CRITICAL POC
9.8 Dec 18

A library injection vulnerability exists in Microsoft Teams (work or school) 24046.2813.2770.1094 for macOS. Rated criti
CVE-2024-41145 CRITICAL POC
9.8 Dec 18

A library injection vulnerability exists in the WebView.app helper app of Microsoft Teams (work or school) 24046.2813.27
CVE-2024-41138 CRITICAL POC
9.8 Dec 18

A library injection vulnerability exists in the com.microsoft.teams2.modulehost.app helper app of Microsoft Teams (work

CVE-2024-45409 CRITICAL POC
9.8 Sep 10

The Ruby SAML library is for implementing the client side of a SAML authorization. Rated critical severity (CVSS 9.8), t
CVE-2022-35929 CRITICAL POC
9.8 Aug 04

cosign is a container signing and verification utility. Rated critical severity (CVSS 9.8), this vulnerability is remote
CVE-2022-31053 CRITICAL POC
9.8 Jun 13

Biscuit is an authentication and authorization token for microservices architectures. Rated critical severity (CVSS 9.8)

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-2012-1723 CRITICAL POC
9.8
CVE-2017-10271 HIGH POC
7.5
CVE-2015-1427 CRITICAL POC
9.8
CVE-2025-3248 CRITICAL POC
9.8

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

EUVD-2026-32918 vulnerability details – vuln.today
Back

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