CVE-2024-33664: Python-jose JWT Bomb DOS Vulnerability

CVE-2024-33664 Overview

CVE-2024-33664 affects python-jose versions through 3.3.0, a widely used Python implementation of JavaScript Object Signing and Encryption (JOSE). Attackers can trigger a denial of service (DoS) by submitting a crafted JSON Web Encryption (JWE) token with an extreme compression ratio. During decode, the library decompresses the payload without bounds, exhausting memory and CPU on the target host. This class of attack is commonly called a "JWT bomb" and mirrors the pattern documented in CVE-2024-21319 for Microsoft Identity Model. Any service accepting untrusted JWE tokens for decoding is exposed.

Critical Impact
Remote unauthenticated attackers can exhaust server resources by submitting a single small JWE token that expands to a very large payload during decoding, degrading or halting authentication services.

Affected Products

python-jose 3.3.0 and earlier
Applications embedding python-jose for JWE decoding
Authentication services and APIs consuming compressed JWE tokens

Discovery Timeline

2024-04-26 - CVE-2024-33664 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-33664

Vulnerability Analysis

The flaw is an uncontrolled resource consumption issue [CWE-400]. python-jose supports the optional zip header parameter in JWE tokens, which indicates that the plaintext was compressed before encryption. When decoding a JWE, the library decrypts the payload and then decompresses it without enforcing an upper bound on the decompressed size.

An attacker crafts a JWE whose ciphertext, once decrypted, decompresses to a very large buffer. Because DEFLATE and similar algorithms achieve compression ratios exceeding 1000:1 on repetitive input, a token of a few kilobytes can inflate to hundreds of megabytes or gigabytes in memory. The decode operation blocks the worker process, and repeated requests exhaust available memory across the host.

Remediation guidance appears in the upstream discussion at GitHub Issue #344 and Pull Request #345. Additional analysis is available in the Vicarius write-up on the JWT bomb.

Root Cause

The decoding path invokes decompression on attacker-controlled ciphertext with no maximum output size, no streaming limits, and no timeout. The zip header value drives which decompressor is used, and the library trusts the resulting length.

Attack Vector

An unauthenticated attacker sends a JWE token containing the zip header set to a supported algorithm such as DEF. The encrypted payload compresses a large repeating byte pattern. When the target application calls the jwe.decrypt or jwt.decode path, decompression allocates memory proportional to the original uncompressed size, producing a denial of service condition.

Detection Methods for CVE-2024-33664

Indicators of Compromise

Sudden spikes in memory consumption by Python worker processes handling authentication endpoints.
Repeated inbound JWE tokens containing the zip header parameter, especially with value DEF.
HTTP 5xx errors and process restarts correlated with JWE decode operations.
Elevated CPU usage in threads executing zlib decompression during token validation.

Detection Strategies

Instrument JWE decode paths to log token size, zip header presence, and post-decompression payload size.
Inspect the JWE protected header at the edge and flag tokens declaring compression when it is not expected in your protocol.
Alert on process memory growth exceeding a defined threshold within short request windows on authentication services.

Monitoring Recommendations

Track python-jose versions across your inventory and flag deployments at or below 3.3.0.
Monitor web application firewall (WAF) logs for JWE tokens with high entropy payloads and zip headers.
Correlate application performance monitoring (APM) latency spikes with jose decode call stacks.

How to Mitigate CVE-2024-33664

Immediate Actions Required

Inventory all services depending on python-jose and prioritize internet-facing authentication components.
Reject JWE tokens containing the zip header at the API gateway or WAF where compressed JWE is not required.
Impose a strict maximum size on inbound JWE tokens and enforce per-request memory and CPU limits on worker processes.

Patch Information

As of the latest NVD update, no fixed upstream release of python-jose addresses this specific issue. Track Pull Request #345 and Issue #344 for the fix. Consider migrating to an actively maintained JOSE library such as jwcrypto or authlib that enforces bounds on decompressed payload size.

Workarounds

Wrap jwe.decrypt and jwt.decode calls in a subprocess or worker with a memory ceiling enforced by resource.setrlimit.
Pre-parse the JWE protected header and drop tokens whose zip value is not on an allowlist.
Apply request-level rate limiting on authentication endpoints to bound the blast radius of DoS attempts.

bash

# Configuration example: block JWE tokens with the zip header at an nginx edge
# by inspecting the base64url-encoded protected header prefix.
map $http_authorization $jwe_has_zip {
    default 0;
    "~*\"zip\"\s*:\s*\"DEF\"" 1;
}

server {
    location /auth/ {
        if ($jwe_has_zip) { return 400; }
        client_max_body_size 8k;
        proxy_pass http://auth_backend;
    }
}