CVE-2024-29371 Overview
CVE-2024-29371 is a denial-of-service vulnerability in the jose4j library before version 0.9.6. The flaw enables attackers to submit a malicious JSON Web Encryption (JWE) token containing a payload with an exceptionally high compression ratio. When the server processes and decompresses the token, it consumes excessive memory and CPU resources. This is commonly referred to as a zip bomb attack against the JWE decompression routine. The vulnerability affects applications using jose4j to validate or decrypt JWE tokens from untrusted sources.
Critical Impact
A single unauthenticated network request containing a crafted JWE token can exhaust server memory and processing capacity, leading to application unavailability.
Affected Products
- jose4j versions prior to 0.9.6
- Java applications consuming JWE tokens via the jose4j library
- Identity and authentication services relying on jose4j for JOSE processing
Discovery Timeline
- 2025-12-17 - CVE-2024-29371 published to NVD
- 2026-01-23 - Last updated in NVD database
Technical Details for CVE-2024-29371
Vulnerability Analysis
The vulnerability falls under [CWE-1259] (Improper Restriction of Security Token Assignment) and represents an algorithmic complexity attack against decompression logic. JSON Web Encryption supports an optional zip header parameter indicating that the plaintext was compressed before encryption, typically with DEF (DEFLATE). The jose4j library decompresses this content during token processing.
Without an enforced output size limit, an attacker can craft a small JWE token whose compressed payload expands into gigabytes of data. The decompression operation allocates memory and consumes CPU cycles proportional to the expanded size, not the input size. The attack does not require authentication or user interaction and is delivered over the network.
Root Cause
The root cause is missing bounds enforcement on the decompressed plaintext size during JWE processing. The library trusted the zip parameter and decompressed the payload to completion without monitoring the output buffer growth against a maximum threshold. Version 0.9.6 introduces protective limits on decompression output.
Attack Vector
An attacker generates a JWE token using the DEF compression algorithm and packs a highly compressible plaintext such as a long sequence of repeating null bytes. The compressed ciphertext remains small enough to pass typical request size filters. When the target service decrypts and decompresses the token, the runtime allocates memory for the expanded payload. Repeated submissions multiply the resource pressure, causing OutOfMemoryError exceptions, garbage collection thrashing, or full service unavailability. Technical detail is available at the jose4j Bitbucket issue tracker.
Detection Methods for CVE-2024-29371
Indicators of Compromise
- Sudden spikes in Java heap usage or OutOfMemoryError exceptions correlated with inbound JWE traffic
- Unusually small JWE tokens that produce large decompressed payloads during processing
- High CPU utilization on JOSE-processing services following requests carrying the zip header value DEF
- Repeated requests from a single source containing JWE tokens with compression headers
Detection Strategies
- Inspect application logs for JWE parsing exceptions, memory allocation failures, or thread pool exhaustion
- Inventory dependencies and flag any service shipping jose4j at a version lower than 0.9.6
- Add request middleware to log JWE header parameters and alert when the zip parameter is present on tokens from untrusted issuers
Monitoring Recommendations
- Track JVM heap, GC pause time, and thread counts on services that process JWE tokens
- Monitor request latency distributions for token validation endpoints and alert on sustained tail latency increases
- Forward application and runtime telemetry to a centralized analytics platform for correlation across hosts
How to Mitigate CVE-2024-29371
Immediate Actions Required
- Upgrade jose4j to version 0.9.6 or later across all Java services
- Audit transitive dependencies in build manifests such as pom.xml and build.gradle for vulnerable jose4j versions
- Restart affected services after dependency updates to ensure the patched library is loaded
Patch Information
The maintainers addressed the issue in jose4j0.9.6 by enforcing limits on decompressed output during JWE processing. Patch details and discussion are tracked in the official Bitbucket issue.
Workarounds
- Reject inbound JWE tokens that include a zip header parameter when compression is not required by the protocol
- Enforce maximum request body sizes at the reverse proxy or API gateway tier
- Apply per-source rate limiting on endpoints that decrypt or validate JWE tokens
- Run JOSE-processing components with strict JVM heap limits so resource exhaustion is contained to a single process
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
