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
Source GCVE Database
Not known to be exploited · CVSS 6.9 Medium : upgrade to 1.2.5 when convenient.
Data as of 5 Nov 2026, 22:34 UTC
Sources agree
| CNA (EEF) | CVSS 4.0 | 6.9 |
|---|---|---|
| CISA-ADP | CVSS 3.1 | 6.2 |
- Patch
- Available – fixed in 1.2.5, e34f4a4f6dc18d990d1cece2d5fceef8e934a195
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 5 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.
What to do
Upgrade ezstd to 1.2.5; ezstd to e34f4a4f6dc18d990d1cece2d5fceef8e934a195.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| silviucppezstd | Affected
| Fixed in
|
| ezstdsilviucpp/ezstd | Affected
| Fixed in
|
Hexezstdpkg:hex/ezstdOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
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.
References
- nvd.nist.gov/vuln/detail/CVE-2026-119434 (opens in a new tab)
- github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423 (opens in a new tab)
- github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195 (opens in a new tab)
- cna.erlef.org/cves/CVE-2026-119434.html (opens in a new tab)
- github.com/silviucpp/ezstd/releases/tag/v1.2.5 (opens in a new tab)
- osv.dev/vulnerability/EEF-CVE-2026-119434 (opens in a new tab)