Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-11-05T21:18:41.210Z",
  "pubdate": "2026-11-05T21:18:41.210Z",
  "executiveSummary": "This vulnerability is an Improper Handling of Highly Compressed Data (Data Amplification) flaw affecting the ezstd library for Erlang. The issue resides in the NIF (Native Implemented Function) path used for decompression with a dictionary.\nBy supplying a maliciously crafted zstd frame that declares a disproportionately large content size relative to the actual compressed frame size, an attacker can trigger an uncontrolled memory allocation.\nBecause the allocation occurs within the NIF layer, it bypasses the standard Erlang VM safety checks. This forces the operating system to terminate the entire Erlang VM node due to memory exhaustion (OOM), leading to a complete Denial of Service (DoS).\nThe vulnerability affects ezstd versions from 1.0.5 up to, but not including, 1.2.5. Exploitation does not require special authentication or privileges, provided the attacker can influence the input passed to the vulnerable decompression function.\nThis represents a high-risk security flaw for applications relying on untrusted external data in distributed systems, as it allows for remote node-wide service disruption.",
  "technicalDetails": "The root cause of this vulnerability is an inconsistency in input validation between different code paths within the ezstd NIF wrapper. While the standard ezstd:decompress/1 function enforces a 1 GiB MAX_BUFFER_SIZE limit to prevent excessive memory allocation, the dictionary-aware decompression function, zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc, fails to implement this security boundary.\nThe vulnerability is triggered when an attacker provides a small, highly compressed zstd frame (such as one utilizing RLE blocks) that specifies an inflated content size via ZSTD_getFrameContentSize. In the affected versions, the NIF passes this attacker-controlled size directly to enif_make_new_binary without verifying if the requested allocation aligns with system resource constraints or predefined safety thresholds.\nThe exploitation flow proceeds as follows: First, the attacker identifies an entry point where the application calls ezstd:decompress_using_ddict/2. Second, the attacker crafts a zstd frame that appears small on disk but advertises a multi-gigabyte decompressed payload. Third, the crafted frame is submitted to the target application. Fourth, the zstd_nif_decompress_using_ddict function invokes ZSTD_getFrameContentSize to read the malicious size. Fifth, the NIF invokes enif_make_new_binary, attempting to allocate the full declared memory volume on the heap. Finally, because this allocation is performed at the C level outside of the Erlang scheduler's memory management oversight, the operating system kernel triggers an OOM killer event, resulting in the abrupt termination of the entire Erlang VM instance rather than isolating the error to a single process.\nThis behavior creates a significant data amplification attack vector. A frame as small as 65,550 bytes can be used to request a 2 GiB allocation. The lack of bounds checking in the dictionary-aware path renders the application vulnerable to immediate, process-wide crashes initiated by simple, low-bandwidth network packets."
}