Skip to main content

PyJWT CVE-2026-48526

| EUVDEUVD-2026-32917 HIGH
Improper Authentication (CWE-287)
2026-05-28 GitHub_M GHSA-xgmm-8j9v-c9wx PYSEC-2026-179
7.4
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Retrieve issuer public key from JWKS endpoint
  2. Delivery
    Craft JWT with alg:HS256 and forged claims
  3. Exploit
    Sign token using public key bytes as HMAC secret
  4. Execution
    Submit token to PyJWT-protected API
  5. Persist
    Library validates HMAC and accepts forgery
  6. Impact
    Access resources as impersonated identity

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK

2 techniques across 2 tactics: Defense Evasion, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires three specific conditions: (1) the calling application invokes pyjwt with an algorithms allowlist that includes at least one HMAC algorithm (HS256/HS384/HS512) alongside an asymmetric algorithm such as RS256/ES256 - applications that pin to a single algorithm family are not vulnerable; (2) the attacker can obtain the issuer's public key, which is trivial when the deployment exposes a JWKS endpoint or publishes the key in documentation but harder in closed federations; (3) the verifier passes the public key material to pyjwt in a form (raw bytes, PEM string, or JWK dict) that the HMAC path will accept as a secret. Attack complexity is rated High in the CVSS vector because the vulnerable mixed-algorithm configuration is a non-default coding pattern; no user interaction or pre-existing authentication is needed once those conditions are met.

Impact

The CVSS 3.1 score of 7.4 with vector AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:N reflects high confidentiality and integrity impact under network reach with no authentication required, but acknowledges high attack complexity - exploitation depends on the relying application accepting multiple algorithm families and exposing or otherwise leaking the issuer public key (commonly the case via /.well-known/jwks.json endpoints, so AC:H may understate real-world feasibility). No EPSS score, KEV listing, or POC indicator was provided in the input, so practical exploitation pressure cannot be quantified from this data alone; however, algorithm-confusion attacks against JWT libraries are well-precedented (CVE-2022-29217 in PyJWT itself, plus equivalents in jsonwebtoken and golang-jwt), and proof-of-concept code for the attack class is widely published. SSVC inputs (automatable, exploitation status) are not supplied. The realistic priority depends heavily on whether downstream applications pass untrusted algorithm hints into pyjwt.decode with a mixed-algorithm allowlist.

Exploit ScenarioDerived

An attacker fetches the target application's public signing key from its publicly exposed JWKS endpoint, then forges a JWT claiming an arbitrary identity (e.g., admin user) with the alg header set to HS256 and signs it using the PEM bytes of that public key as the HMAC secret. The attacker submits the forged token to the protected API; because PyJWT accepts both RS256 and HS256, it computes HMAC-SHA256 over the token using the supplied key and matches the attacker's signature, granting authenticated access without ever possessing the private key.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 28, 2026

Authentication bypass in PyJWT versions prior to 2.13.0 allows remote attackers to forge valid JSON Web Tokens by exploiting an algorithm confusion flaw where the library fails to validate that a JSON Web Key intended for asymmetric verification is not reused as an HMAC shared secret. An attacker who knows the issuer's public key (typically distributed openly via JWKS endpoints) can sign HMAC-algorithm tokens with that public key and have them accepted as legitimate. No public exploit identified at time of analysis, though the underlying algorithm-confusion class is a well-documented JWT attack pattern.

RemediationAI

Upgrade PyJWT to vendor-released patch version 2.13.0 or later (pip install --upgrade 'pyjwt>=2.13.0') as documented in advisory GHSA-xgmm-8j9v-c9wx (https://github.com/jpadilla/pyjwt/security/advisories/GHSA-xgmm-8j9v-c9wx). As a compensating control until upgrade is possible, restrict the algorithms parameter passed to jwt.decode() to a single family - pass algorithms=['RS256'] (or whichever single asymmetric algorithm your issuer uses) rather than a list that includes both HMAC and asymmetric algorithms; the side effect is loss of algorithm agility during key rotation. Additionally, ensure verification code explicitly loads the issuer's public key as a cryptography PublicKey object rather than raw bytes/PEM strings, so it cannot silently be reinterpreted as an HMAC secret. Audit JWKS-consuming code paths and reject tokens whose alg header does not match the key type retrieved from the JWKS kid.

Affected VersionsENISA

pyjwt < 2.13.0

Affected Packages

pypi pyjwt fix: 2.13.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

PyJWT (cpe:2.3:a:jpadilla:pyjwt) is the most widely used Python implementation of RFC 7519 JSON Web Tokens, commonly embedded in Flask, Django, and FastAPI authentication stacks. The flaw is a classic algorithm-confusion vulnerability mapped to CWE-287 (Improper Authentication): when an application configures the verifier to accept both asymmetric algorithms (RS256/ES256, which use a public key) and symmetric algorithms (HS256/HS384/HS512, which use a shared secret), PyJWT did not reject the case where the caller-supplied key was a JWK or asymmetric public key being fed into the HMAC path. Because the public key is, by design, public, an attacker can craft an HS256 token using that key bytes as the HMAC secret, and the verifier will compute the same HMAC and accept the token as valid - bypassing the trust assumption that only the holder of the private key could have produced it.

Know when Pyjwt gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.4 HIGH
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
SUSE HIGH
Red Hat 7.4 HIGH

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

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

Lifecycle Timeline

1
Patch available
May 28, 2026 - 17:01 EUVD

DescriptionCVE.org

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, when the verifier is decoding JSON Web Tokens, while supporting both asymmetric and HMAC algorithms, the library does not validate use of JSON Web Keys in HMAC algorithm, allowing attacker to use the issuer public key as the secret key for HMAC algorithm. This vulnerability is fixed in 2.13.0.

Blast Radius

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

Ecosystem-wide dependent count for version 2.13.0.

Executive ViewAI

Why It Matters

PyJWT versions prior to 2.13.0 contain an algorithm confusion vulnerability (CVE-2026-48526, CVSS 7.4) enabling attackers to forge valid authentication tokens and bypass access controls; no public exploit identified at time of analysis. Any organization using affected PyJWT versions faces immediate risk of unauthorized system access through token forgery. This vulnerability requires urgent remediation across all affected deployments.

Business Impact: High
Compensating Controls

Disable HMAC algorithm support in all applications; enforce asymmetric-signature-only token verification; implement public key pinning to prevent key substitution; validate token algorithm claims against authorized-algorithms whitelist; deploy Web Application Firewall rules to block HMAC-signed tokens; enable real-time logging and anomaly detection for token validation failures and algorithm mismatches.

Threat Intelligence Overview

EPSS Score
0.0%
Top 94% exploitable
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Social Media
1
Sightings
Data Quality
8 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA MSRC Vendor CIRCL GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC Yes
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Total

Priority Score

57
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +37
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Pyjwt

View all
CVE-2026-102266 CRITICAL POC
9.1 Sep 28

Forged HS256 JSON Web Tokens can be accepted as authentic by PyJWT (pip package PyJWT) versions 2.13.0 through 2.13.x wh

CVE-2026-102275 HIGH POC
8.2 Sep 28

Improper validation in PyJWT 2.1.0 through 2.14.0 allows an attacker who already holds a stolen sender-constrained (DPoP

CVE-2026-102274 HIGH POC
7.5 Sep 28

Denial of service in PyJWT 2.9.0 through 2.13.0: a single malformed RSA JWK embedded in a JWK Set aborts construction of

CVE-2026-101918 HIGH POC
7.5 Sep 28

Unauthenticated denial of service in the PyJWT Python library (versions 2.0.0a1 through 2.14.0) allows a remote attacker

CVE-2024-53861 HIGH POC
7.5 Nov 29

pyjwt is a JSON Web Token implementation in Python. Rated high severity (CVSS 7.5), this vulnerability is remotely explo

CVE-2026-103001 MEDIUM POC
6.5 Sep 30

Reuse of a caller-supplied options mapping in PyJWT 2.11.0 through 2.13.0 can silently leave registered-claim verificati

CVE-2026-102265 MEDIUM POC
5.3 Sep 28

Malformed JSON Web Token headers can cause an uncaught RecursionError in PyJWT 2.13.0 through versions before 2.14.0, re

CVE-2026-48525 MEDIUM POC
5.3 May 28

Uncontrolled resource consumption in PyJWT 2.8.0-2.12.1 exposes any service that verifies detached JWS tokens to unauthe

CVE-2026-102268 CRITICAL
9.1 Sep 28

Signature forgery in PyJWT before 2.14.0 allows an attacker who knows a target's asymmetric public key to forge HMAC-aut

CVE-2026-102267 CRITICAL
9.1 Sep 28

JWKS trust-boundary bypass in PyJWT's PyJWKClient allows a configured trusted JWKS endpoint that returns an HTTP 3xx red

CVE-2026-48524 LOW POC
3.7 May 28

Unconstrained outbound JWKS requests in PyJWT's PyJWKClient.get_signing_key() allow unauthenticated remote attackers to

CVE-2026-101917 HIGH
7.5 Sep 28

Unauthenticated attackers can amplify outbound HTTP traffic from any application that validates JWTs with PyJWT's PyJWKC

Vendor StatusVendor

SUSE

Severity: High
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

References

Advisories & patches
ADVISORY https://github.com/pypa/advisory-database/tree/main/vulns/pyjwt/PYSEC-2026-179.yaml ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-48526 ADVISORY https://ubuntu.com/security/notices/USN-8823-1 ADVISORY https://vuldb.com/vuln/366778 REF https://access.redhat.com/errata/RHSA-2026:24069 REF https://access.redhat.com/errata/RHSA-2026:25902 REF https://access.redhat.com/errata/RHSA-2026:25928 REF https://access.redhat.com/errata/RHSA-2026:26206 REF https://access.redhat.com/errata/RHSA-2026:28571 REF https://access.redhat.com/errata/RHSA-2026:30076 REF https://access.redhat.com/errata/RHSA-2026:30088 REF https://access.redhat.com/errata/RHSA-2026:30089 REF https://access.redhat.com/errata/RHSA-2026:33683 REF https://access.redhat.com/errata/RHSA-2026:34160 REF https://access.redhat.com/errata/RHSA-2026:34365 REF https://access.redhat.com/errata/RHSA-2026:34374 REF https://access.redhat.com/errata/RHSA-2026:35835 REF https://access.redhat.com/errata/RHSA-2026:35836 REF https://access.redhat.com/errata/RHSA-2026:35837 REF https://access.redhat.com/errata/RHSA-2026:35845 REF https://access.redhat.com/errata/RHSA-2026:36350 REF https://access.redhat.com/errata/RHSA-2026:37275 REF https://access.redhat.com/errata/RHSA-2026:40967 REF https://access.redhat.com/errata/RHSA-2026:41066 REF https://access.redhat.com/errata/RHSA-2026:42132 REF https://access.redhat.com/errata/RHSA-2026:42142 REF https://access.redhat.com/errata/RHSA-2026:42144 REF https://access.redhat.com/errata/RHSA-2026:42644 REF https://access.redhat.com/errata/RHSA-2026:42796 REF https://access.redhat.com/errata/RHSA-2026:43038 REF https://access.redhat.com/errata/RHSA-2026:48085 REF https://access.redhat.com/errata/RHSA-2026:50222 REF https://access.redhat.com/errata/RHSA-2026:50223 REF https://access.redhat.com/errata/RHSA-2026:50263 REF https://access.redhat.com/errata/RHSA-2026:50319 REF https://access.redhat.com/errata/RHSA-2026:50336 REF https://access.redhat.com/errata/RHSA-2026:50340 REF https://access.redhat.com/errata/RHSA-2026:50904 REF https://access.redhat.com/errata/RHSA-2026:60520 REF https://access.redhat.com/errata/RHSA-2026:7634 REF https://access.redhat.com/security/cve/CVE-2026-48526 REF https://bugzilla.redhat.com/show_bug.cgi?id=2482734 REF https://github.com/jpadilla/pyjwt/security/advisories/GHSA-xgmm-8j9v-c9wx REF https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48526.json

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