CVE-2026-119434 in ezstd
Summary
by MITRE • 11/05/2026
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to ezstd:decompress_using_ddict/2 to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.
zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads the frame's declared content size with ZSTD_getFrameContentSize and passes it directly to enif_make_new_binary, without the 1 GiB MAX_BUFFER_SIZE check that ezstd:decompress/1 applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by ezstd:decompress/1 but is fully allocated and decompressed by the dictionary path. The allocation happens inside a NIF, so when it exceeds the memory available to the VM the operating system kills the whole node rather than the calling process.
This issue affects ezstd: from 1.0.5 before 1.2.5.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in the silviucpp ezstd library represents a critical failure in input validation and resource management, specifically categorized under CWE-400 Uncontrolled Resource Consumption. This flaw arises from an inconsistency in how different API endpoints within the library handle decompression requests for zstd compressed data. The core issue lies in the disparity between two primary functions: ezstd:decompress/1 and ezstd_nif_decompress_using_ddict/2. While the former implements a protective check against excessively large allocations by enforcing a maximum buffer size limit, typically set to one gigabyte, the latter function bypasses this safeguard entirely. This discrepancy creates an exploitable path where an attacker can trigger a denial of service condition through data amplification techniques that exploit the difference in validation logic between these two code paths.
From a technical perspective, the vulnerability is triggered when an attacker supplies a specifically crafted zstd frame to the dictionary-based decompression function. The malicious payload consists of a relatively small compressed file, approximately sixty-five thousand five hundred fifty bytes in size, which utilizes Run-Length Encoded blocks to declare a content size of two gigabytes within its header metadata. When this frame is processed by ezstd_nif_decompress_using_ddict/2, the underlying C++ implementation calls ZSTD_getFrameContentSize to retrieve the declared uncompressed size and immediately passes this value directly to enif_make_new_binary for memory allocation. Unlike the standard decompression path, there is no intermediate check to verify if the requested allocation exceeds system limits or predefined safety thresholds such as MAX_BUFFER_SIZE. Consequently, the Erlang Virtual Machine attempts to allocate two gigabytes of contiguous memory based solely on the untrusted input provided in the frame header.
The operational impact of this vulnerability is severe and results in a complete denial of service for the affected application node. Because the vulnerable allocation occurs within a Native Implemented Function NIF context, it operates outside the standard garbage collection and process isolation mechanisms that normally protect individual Erlang processes from consuming excessive resources. When the memory request exceeds the available physical or virtual memory on the host system, the operating system's out-of-memory killer intervenes to terminate the entire VM node rather than just the offending process. This leads to a catastrophic failure where all services running within that Erlang instance are abruptly terminated, causing significant downtime and potential data loss for any dependent systems relying on this service.
This vulnerability aligns with ATT&CK technique T1498 Network Denial of Service, specifically sub-technique T1498.002 Resource Exhaustion via Amplification Attacks. The attacker leverages the decompression algorithm's ability to expand small inputs into massive memory requirements, a classic amplification vector often seen in protocols like DNS or NTP but here applied directly within an application layer library. By exploiting this resource exhaustion flaw, an adversary can effectively take down critical infrastructure components that depend on high-performance data compression and decompression services provided by the ezstd library.
The issue affects versions of the ezstd Erlang package from 1.0.5 up to but not including version 1.2.5. To mitigate this risk, organizations must ensure they are running a patched version of the library where the dictionary-based decompression path has been updated to include the same rigorous input validation and size checks present in the standard decompression function. Until an upgrade is performed, administrators should consider implementing network-level filtering or application-layer gateways that inspect incoming data payloads for suspicious compression ratios or header anomalies before they reach the vulnerable code paths. Additionally, deploying resource limits at the operating system level via cgroups or similar mechanisms can help contain the blast radius of such memory exhaustion attempts, although upgrading to a fixed version remains the most effective remediation strategy.