CVE-2026-39373: 
Python vulnerability analysis and mitigation

CVE-2026-39373 is a JWE ZIP decompression bomb vulnerability in the JWCrypto Python library (latchset/jwcrypto) that allows unauthenticated attackers to exhaust server memory by sending crafted JWE tokens with ZIP compression. It affects all versions of jwcrypto up to and including 1.5.6, and is fixed in version 1.5.7. The vulnerability was published on April 7, 2026, and represents a bypass of the prior fix for CVE-2024-28102 (GHSA-j857-7rvv-vj97). It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification) and CWE-770 (Allocation of Resources Without Limits or Throttling). The prior patch for CVE-2024-28102 added a 250KB size check on the compressed input in jwcrypto/jwe.py, but the check is applied to the compressed bytes (data) rather than the decompressed output: the call zlib.decompress(data, -zlib.MAX_WBITS) proceeds without any limit on the resulting plaintext size. An unauthenticated attacker can craft a JWE token with the zip: DEF header that is under the 250KB input limit but decompresses to approximately 100MB, triggering memory exhaustion during the deserialize() call. No authentication or special privileges are required; any endpoint that accepts and deserializes JWE tokens is a valid attack surface (GitHub Advisory, GitHub Advisory).

Successful exploitation causes a Denial of Service (DoS) through memory exhaustion on the server processing the malicious JWE token. The impact is limited to availability — there is no confidentiality or integrity impact. Memory-constrained systems (e.g., embedded devices, containers with low memory limits) are most at risk of service disruption or crash. Downstream products incorporating JWCrypto, including IBM QRadar Suite Software, IBM Security QRadar EDR, and Red Hat Ansible Automation Platform, are also affected (GitHub Advisory, Red Hat Bugzilla).

A public proof-of-concept (PoC) is included in the official security advisory and demonstrates the attack entirely within a local Python process — it does not constitute a weaponized exploit targeting remote systems. There is no confirmed evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.036–0.105%, indicating a low probability of near-term exploitation (GitHub Advisory, GitHub Advisory).

1. Identify a target: Locate a service that accepts and deserializes JWE tokens using a vulnerable version of JWCrypto (≤ 1.5.6), such as an API endpoint that processes authentication tokens.
2. Craft a decompression bomb token: Using a Python environment with JWCrypto, generate a JWE token with zip: DEF (DEFLATE compression) whose plaintext is a large repetitive payload (e.g., 100MB of repeated bytes), which compresses to well under 250KB.
3. Serialize the token: Call token.serialize(compact=True) to produce a compact JWE string — the resulting token will be approximately 132KB, safely under the 250KB input size check.
4. Submit the token to the target: Send the crafted compact JWE token to the vulnerable endpoint (e.g., as a Bearer token or in a request body field that triggers JWE deserialization).
5. Trigger memory exhaustion: The server calls jwe.JWE().deserialize(token, key), which passes the compressed-size check but then calls zlib.decompress() without output size limits, allocating ~100MB of memory per request and potentially crashing or degrading the service (GitHub Advisory).

• Network: Repeated HTTP requests to JWE token processing endpoints (e.g., authentication or token exchange APIs) with compact JWE payloads in the range of 100–250KB, particularly those using the zip header field (DEF algorithm).
• Logs: Application logs showing sudden spikes in memory usage or out-of-memory (OOM) errors correlated with JWE deserialization calls; Python process crash logs or OOM killer events in system logs (/var/log/syslog, dmesg).
• Process: Abnormal memory consumption by the Python process hosting the JWCrypto-based service, potentially reaching system memory limits; repeated process restarts or watchdog-triggered restarts.
• File System: No specific file artifacts expected, as this is a runtime memory exhaustion attack with no persistent payload.

The primary remediation is to upgrade JWCrypto to version 1.5.7 or later, which implements proper decompressed output size validation before allocating memory (GitHub Advisory). Red Hat has issued patches via RHSA-2026:13508 (Ansible Automation Platform 2.6 for RHEL 10/9), RHSA-2026:13512 (Ansible Automation Platform 2.5 for RHEL 9/8), RHSA-2026:19042 (RHEL 10), and RHSA-2026:19197 (RHEL 9) (Red Hat Bugzilla). As interim workarounds, operators should implement memory limits on the service process (e.g., via cgroups or container resource limits), apply rate limiting on JWE token submission endpoints, and monitor for abnormal memory consumption patterns during token processing.

The JWCrypto maintainer (simo5) noted in the advisory that the original vulnerability report was likely AI-generated ('AI slop') and that the proposed fix in the report was itself flawed — it would have decompressed data fully before checking size, defeating the purpose. The maintainer characterized the severity as low, stating that memory exhaustion is bounded (not unlimited) and that the prior fix did provide some protection. Red Hat's Bugzilla entry reflects this assessment, with a comment from Simo Sorce indicating the severity should be classified as low rather than moderate (GitHub Advisory, Red Hat Bugzilla).