CVE-2026-48525: 
Python vulnerability analysis and mitigation

CVE-2026-48525 is an unauthenticated Denial of Service vulnerability in PyJWT, a JSON Web Token implementation in Python. Affecting versions 2.8.0 through 2.12.1, the flaw allows a remote attacker to force unbounded CPU and memory consumption by supplying an arbitrarily large Base64URL-encoded payload segment in detached JWS tokens using the unencoded-payload option (b64=false, RFC 7797). The vulnerability was published on May 28, 2026, and fixed in version 2.13.0. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause (CWE-400: Uncontrolled Resource Consumption) lies in the decode order within jwt/api_jws.py. Specifically, decode_complete() calls _load(jwt) first, which unconditionally performs base64url_decode(payload_segment) — an expensive operation — before checking whether b64=false applies. When b64=false is detected, PyJWT discards the decoded payload and substitutes the caller-provided detached_payload, meaning the initial decode is entirely wasted work. An attacker exploits this by crafting a JWS compact token with "b64": false in the header and inflating the middle payload segment to millions of Base64URL characters; the server performs the expensive decode and memory allocation before rejecting the invalid signature, making the attacker's cost negligible while the server's cost scales linearly with payload size (GitHub Advisory). No authentication or valid signing key is required to trigger the vulnerable code path.

Successful exploitation causes CPU exhaustion and excessive memory allocation on any server endpoint that verifies detached JWS tokens using PyJWT. PoC results demonstrate that a single malicious request with an 8-million-character payload segment consumes approximately 23 ms of server processing time and ~32 MB of peak memory allocations, even when the signature is invalid and rejected with HTTP 401. Under concurrent burst conditions (e.g., 20 simultaneous requests), client-observed latency rises to over 1 second due to worker starvation and head-of-line blocking, resulting in service degradation or complete unavailability. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory).

1. Reconnaissance: Identify services that accept and verify detached JWS tokens using PyJWT versions 2.8.0–2.12.1 (e.g., webhook verification endpoints, signed HTTP request handlers).
2. Craft malicious JWS token: Construct a JWS compact serialization token with a header containing "b64": false and "crit": ["b64"], and inflate the middle payload segment to millions of Base64URL-encoded characters (e.g., 8,000,000 characters).
3. Send request to verification endpoint: Submit an HTTP POST request to the target's detached JWS verification endpoint, including the crafted token and any arbitrary detached_payload value.
4. Force resource consumption: PyJWT's _load() function decodes the inflated payload segment unconditionally, consuming ~23 ms CPU time and ~32 MB memory per request before rejecting the invalid signature with HTTP 401.
5. Amplify via concurrent flooding: Use the flood_localhost.py-style approach to send N concurrent requests simultaneously, causing worker queue saturation and head-of-line blocking, resulting in service degradation or unavailability for legitimate users (GitHub Advisory).

• Network: High volume of HTTP POST requests to JWS/JWT verification endpoints from one or more source IPs; requests with unusually large body sizes (hundreds of KB to tens of MB) containing JWT-like structures.
• Logs: HTTP 401 responses with InvalidSignatureError at high frequency from the same or rotating source IPs; server access logs showing abnormally long request processing times for token verification endpoints.
• Process/Resource: Sudden spikes in CPU utilization and memory allocation on application worker processes handling JWT verification; worker thread/process starvation observable via application performance monitoring.
• Application: Log entries referencing PyJWS.decode() or _load() with large token lengths (e.g., token_len in the hundreds of thousands or millions of characters) (GitHub Advisory).

Upgrade PyJWT to version 2.13.0 or later, which fixes the decode order so that the payload segment is not Base64URL-decoded before b64=false handling is enforced (GitHub Advisory). If immediate patching is not possible, enforce strict maximum token/request body size limits at the HTTP boundary (proxy, gateway, or web framework level) to bound the amplification effect — deployments with ≤2 MB body-size caps significantly reduce exposure. Additional mitigations include applying rate limiting on verification endpoints and, if detached JWS (b64=false) is not required by the application, explicitly rejecting tokens whose headers contain "b64": false.

The vulnerability was reported by researcher thesmartshadow and disclosed via GitHub Security Advisory on May 21, 2026. The advisory notes that practical impact is bounded by upstream request body-size limits, and rates the severity as Moderate (5.3). The Solus Linux community referenced the fix in their Week 23 2026 update discussion, and the vulnerability was picked up by multiple CVE tracking services shortly after disclosure (GitHub Advisory).