3.7

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-48524

CVE-2026-48524: PyJWT: PyJWKClient unbounded JWKS endpoint requests via attacker-controlled kid values (DoS)

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-48524

CVE-2026-48524:

3.7

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

SSVC / BOD 26-04 ↗

Exploitation NoneAutomatable NoTech Impact Partial

Select your environment

→SSVCDeferfix on upgrade

Runtime reachability resolves your actual outcome.Book a demo

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
pyjwt	pip	<= 2.12.1	2.13.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability in PyJWT (GHSA-fhv5-28vv-h8m8) is a denial-of-service (DoS) issue within the PyJWKClient. It has two main components.

First, the PyJWKClient.get_signing_key function is the primary entry point for the DoS attack. It is responsible for retrieving a signing key based on the kid (key ID) from a JWT header. If the kid is not found in the local cache, the function triggers an immediate, uncached fetch of the entire JSON Web Key Set (JWKS) from the configured endpoint by calling get_signing_keys(refresh=True). An attacker can exploit this by sending a high volume of JWTs with randomly generated, non-existent kids. This forces the PyJWKClient to issue a continuous stream of HTTP requests to the JWKS endpoint, potentially overwhelming it and causing a DoS. This function would be the top-level application function in a stack trace during an exploit attempt.

Second, the PyJWKClient.fetch_data function, which handles the actual HTTP request to the JWKS endpoint, contained a flaw that exacerbated the DoS condition. In vulnerable versions, the function was structured with a try...except...finally block where the cache update (self.jwk_set_cache.put(...)) occurred in the finally block. If the HTTP request failed for any reason (e.g., the JWKS endpoint became rate-limited due to the attack), an exception would be thrown, and the finally block would execute with an uninitialized jwk_set variable (which defaults to None). This had the effect of wiping the entire JWKS cache. As a result, even legitimate tokens with valid kids could no longer be verified, extending the denial of service to all users of the application until the JWKS endpoint recovered and a successful fetch could occur.

The provided patch specifically addresses the second issue by moving the cache update logic out of the finally block, ensuring that the cache is only written to upon a successful fetch. While get_signing_key was not modified, it remains the function that initiates the vulnerable process. Therefore, both PyJWKClient.get_signing_key and PyJWKClient.fetch_data are critical indicators of this vulnerability.

Vulnerable functions

PyJWKClient.fetch_data

jwt/jwks_client.py

The original implementation used a `finally` block to cache the result of the JWKS fetch. If the fetch failed due to a network error, the `jwk_set` variable would be `None`, and the `finally` block would clear the existing cache. This would cause all subsequent authentication attempts to fail until the JWKS endpoint recovered, turning a transient error into a more severe denial of service. The patch moves the caching logic to only execute on a successful fetch.

PyJWKClient.get_signing_key

jwt/jwks_client.py

This function is the trigger for the vulnerability. When called with a `kid` (key ID) that is not present in its cache, it unconditionally triggers a refresh of the JWKS by calling `get_signing_keys(refresh=True)`. Since the `kid` is taken from an unverified JWT, an attacker can send a stream of tokens with random, unknown `kid`s to force the client to make an unlimited number of HTTP requests to the JWKS endpoint, leading to a denial of service. While not directly modified in the patch, it is the function that initiates the vulnerable workflow.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.