CVE-2026-48525

What it actually does

CVE-2026-48525 is an unauthenticated denial-of-service vulnerability in PyJWT versions 2.8.0 through 2.12.1 when verifying detached JSON Web Signature tokens that use the RFC 7797 unencoded-payload option, indicated by "b64": false. During compact JWS verification, PyJWT incorrectly Base64URL-decodes the payload segment before enforcing detached-payload handling. Because that decoded value is later discarded and replaced with the caller-supplied detached_payload, an attacker can place an arbitrarily large Base64URL string in the compact token’s middle segment to force unnecessary CPU consumption and memory allocation, even when the token is invalid and ultimately rejected. The impact is availability degradation or service exhaustion on applications that accept and verify detached JWS tokens using affected PyJWT versions.

Why it matters to the business

Applications, APIs, or services that verify detached JWS tokens with affected PyJWT versions can be slowed down or made unavailable by unauthenticated remote traffic. This can cause API outages, increased latency, worker exhaustion, autoscaling cost increases, and disruption to services that depend on token verification for request handling. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no reported exploit maturity, but it is network-reachable, low-complexity, and requires no credentials, so exposed token-verification endpoints should still be prioritized for upgrade or request-size mitigation.

How an attack unfolds

An attacker identifies an endpoint that accepts JWT/JWS input and uses PyJWT to verify detached JWS tokens with the unencoded-payload option. The attacker crafts a compact JWS whose protected header declares "b64": false and typically includes "crit": ["b64"], but places a very large Base64URL-compatible string in the middle payload segment. The attacker then sends this token to the target endpoint, often without needing a valid signature or authentication. A vulnerable PyJWT version attempts to Base64URL-decode the oversized middle segment before applying detached-payload semantics. This causes CPU work and memory allocation proportional to the attacker-controlled payload size. Repeated requests can exhaust application workers, memory, CPU, or upstream queues, resulting in degraded service or denial of service.

How to fix it

Upgrade PyJWT to version 2.13.0 or later wherever detached JWS verification may occur. Identify all Python applications, containers, serverless functions, and build artifacts that include PyJWT versions 2.8.0 through 2.12.1. If immediate upgrade is not possible, apply compensating controls: enforce strict maximum request body and header sizes at the reverse proxy, API gateway, and application layer; reject compact JWS tokens whose middle segment exceeds a small expected size when detached payloads are used; rate-limit unauthenticated token-verification endpoints; require authentication or other pre-verification gating where feasible; and isolate token verification into resource-limited workers to reduce blast radius. Avoid accepting detached JWS with "b64": false unless it is explicitly required by the protocol in use.

How to confirm the fix worked

Confirm package versions by inspecting dependency manifests, lock files, container images, and runtime environments for PyJWT. Validate that all deployed runtimes report PyJWT 2.13.0 or later, for example by checking package metadata with pip, pip freeze, pip show PyJWT, poetry.lock, requirements files, SBOMs, or image scanners. Perform a controlled negative test in a non-production environment by sending a detached JWS-style token with "b64": false and an oversized compact payload segment; patched or mitigated services should reject it quickly without significant memory growth, CPU spike, or worker exhaustion. Confirm gateway and application limits reject oversized JWT/JWS inputs before they reach token verification code. Monitor application performance during validation to ensure invalid tokens are handled in bounded time and memory.

Typical attack path

1. Find an internet-accessible API or service endpoint that accepts JWT/JWS tokens or signed request objects.
2. Determine or assume the service verifies detached JWS tokens using PyJWT and supports RFC 7797 "b64": false handling.
3. Create a compact JWS with a protected header containing "b64": false and a critical header reference to b64.
4. Insert an extremely large Base64URL-compatible value into the compact JWS payload segment, even though detached payload verification should not require that segment.
5. Send the malformed or invalid token repeatedly to the target endpoint.
6. Cause the vulnerable PyJWT verifier to decode the oversized segment before rejecting the token, consuming CPU and memory.
7. Repeat or distribute requests to exhaust application workers, trigger memory pressure, increase latency, or make the service unavailable.

How to detect it

To determine whether this vulnerability was already exploited, review logs from API gateways, reverse proxies, WAFs, application servers, and authentication or token-verification services for unusually large JWT/JWS values, especially compact tokens with three dot-separated segments where the middle segment is abnormally large. Focus on endpoints that accept Authorization headers, bearer tokens, signed request objects, webhook signatures, or detached JWS inputs. Look for repeated invalid token or signature failures correlated with high request sizes, CPU spikes, memory growth, worker timeouts, process restarts, 502/503/504 responses, or out-of-memory events. If structured token logging exists, search for protected headers containing "b64": false and "crit": ["b64"]. In application logs, look for bursts of PyJWT exceptions such as InvalidSignatureError or DecodeError associated with large incoming token fields. In infrastructure telemetry, correlate suspicious requests with increased Python process RSS memory, garbage collection pressure, container OOMKilled events, autoscaling events, or elevated p95/p99 latency. Because exploitation may use invalid signatures and leave no successful authentication event, absence of login activity does not rule out attempted exploitation.

• "b64":false
• "b64": false
• "crit":["b64"]
• "crit": ["b64"]
• jwt.exceptions.InvalidSignatureError: Signature verification failed
• jwt.exceptions.DecodeError
• MemoryError
• OOMKilled
• compact JWS
• detached_payload
• Authorization: Bearer eyJ
• ^[A-Za-z0-9_-]+\.[A-Za-z0-9_-]{100000,}\.[A-Za-z0-9_-]+$

What your security team should do

• Inventory all services using PyJWT and prioritize any version from 2.8.0 through 2.12.1 for upgrade to 2.13.0 or later.
• Prioritize externally reachable APIs, authentication-adjacent services, webhook receivers, signed-request processors, and any component that accepts detached JWS tokens.
• Add API gateway, load balancer, or reverse proxy limits for maximum Authorization header size, request body size, and token field length.
• Add application-side validation to reject compact JWS tokens with unexpectedly large payload segments before calling PyJWT verification routines.
• Rate-limit unauthenticated endpoints that perform token parsing or cryptographic verification.
• Review whether RFC 7797 unencoded detached payload support is actually required; disable or reject it where not needed.
• Add monitoring for spikes in invalid JWT/JWS verification failures, request sizes, memory usage, CPU usage, worker restarts, and 5xx responses.
• Search historical logs for oversized compact JWS values and repeated invalid-signature failures from common source addresses.
• Update SBOMs and dependency baselines so PyJWT versions below 2.13.0 are flagged in CI/CD and container scanning.
• Because this issue is not currently KEV-listed and has low EPSS, treat it as a high-priority availability hardening item for exposed services rather than as confirmed active exploitation.