CVE-2026-48525: PyJWT Detached JWS DoS Vulnerability – Patch Guidance

Technical summary

The vulnerability exists in PyJWT versions 2.8.0 through 2.12.1 due to improper processing order in detached JWS token verification with b64=false. When b64=false is specified (per RFC 7797, signifying an unencoded payload), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing detached-payload validation. Although the decoded payload is subsequently discarded and replaced with the caller-supplied detached_payload, the attacker-controlled middle segment acts as a work amplifier: it triggers CPU-intensive Base64URL decoding and memory allocation operations regardless of whether the token's signature is valid or whether the payload will be used. This allows an unauthenticated remote attacker to send arbitrarily large payload segments, inducing uncontrolled resource consumption on the verification endpoint. CWE-400 (Uncontrolled Resource Consumption) captures this class of flaw.

Business impact

Applications that expose JWT verification endpoints—particularly those accepting detached JWS tokens with b64=false—face potential service degradation or availability loss. An attacker can send a stream of malformed tokens with extremely large payloads to exhaust CPU and memory resources without authentication. This is especially problematic for APIs, microservices, or security gateways that validate JWTs on behalf of clients or enforce token policies at scale. While the CVSS score of 5.3 reflects low confidentiality and integrity impact, the unprotected nature of the attack (no authentication required, no special network access needed) and the ease of triggering it make this a material operational risk for affected deployments.

Affected systems

PyJWT versions 2.8.0, 2.9.0, 2.9.1, 2.10.0, 2.10.1, 2.11.0, 2.11.1, 2.12.0, and 2.12.1 are affected. Any Python application linking to these versions and calling PyJWT's JWS verification functions with detached payloads and b64=false will be vulnerable. Verify your exact version via `pip show pyjwt` or your package manager. Organizations should audit internal and third-party Python dependencies to identify exposure. PyJWT 2.13.0 and later contain the fix.

Exploitability

This vulnerability requires no authentication, no privileged access, and no special network positioning—making it highly exploitable by remote, unauthenticated attackers. The only prerequisite is network access to an endpoint that performs PyJWT detached JWS verification. Exploitation is straightforward: craft a token with a very large Base64URL-encoded payload segment and send it repeatedly. No sophisticated tooling or deep cryptographic knowledge is needed. The attack's impact is immediately observable as resource pressure on the target. However, this vulnerability is not yet listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public weaponized exploits have been disclosed, reducing imminent risk but not eliminating the need for remediation.

Remediation

Upgrade PyJWT to version 2.13.0 or later as soon as possible. The fix corrects the processing order by deferring Base64URL decoding until after detached-payload validation rules have been enforced, preventing the work-amplifier attack. For teams unable to upgrade immediately, implement network-level or application-level rate limiting and resource quotas on JWT verification endpoints to mitigate the impact of resource-exhaustion attacks. Additionally, review your use of detached JWS tokens with b64=false; if this functionality is not required, disable it or use standard JWS encoding instead.

Patch guidance

1. Verify your current PyJWT version: `pip show pyjwt` or `python -c "import jwt; print(jwt.__version__)"`. 2. Update to PyJWT 2.13.0 or later via `pip install --upgrade pyjwt`. 3. Validate the update in your package environment and re-run your test suite, paying particular attention to any code paths that verify detached JWS tokens. 4. For production environments, test the update in a staging environment first to ensure no regressions. 5. Check your dependency management (requirements.txt, setup.py, Pipfile, pyproject.toml, etc.) to lock in the patched version and prevent downgrade.

Detection guidance

Monitor your JWT verification endpoints for anomalously large token payloads or rapid sequences of malformed tokens. If you have application logging enabled, inspect logs for decoding errors or resource-consumption spikes correlated with JWT verification operations. Look for patterns such as repeated HTTP 401/403 responses with unusually large request bodies. Use application performance monitoring (APM) tools to identify CPU or memory usage anomalies during JWT processing. If you can inspect the PyJWT code path, add instrumentation around detached JWS verification to track payload sizes and decoding latency. Network-level detection is difficult without packet inspection, but IDS/IPS rules targeting large HTTP payloads may provide indirect signals.

Why prioritize this

Although this vulnerability carries a CVSS score of 5.3 (Medium), its unauthenticated, network-accessible nature and ease of exploitation warrant urgent attention. It poses a direct denial-of-service risk to any exposed JWT verification endpoint. Organizations relying on detached JWS for security workflows (e.g., decoupled signature verification, cross-domain token validation) should prioritize patching within their next security update cycle. The fact that it is not yet in the KEV catalog and has no public weaponized exploits provides a window of opportunity for proactive remediation before widespread abuse begins.

Risk score, explained

The CVSS 3.1 score of 5.3 (Medium) reflects: Attack Vector = Network (attacker needs only network access, no special positioning), Attack Complexity = Low (no special conditions or timing), Privileges Required = None (unauthenticated), User Interaction = None (no click-through or social engineering), Scope = Unchanged, Confidentiality = None, Integrity = None, Availability = Low (a successful attack degrades availability but does not completely eliminate it). While the confidentiality and integrity impacts are zero, the combination of unauthenticated remote exploitability and the ease of triggering resource exhaustion justifies the Medium rating and warrants prioritization above purely information-disclosure vulnerabilities.

Frequently asked questions