Decompression bomb in ezstd:decompress_using_ddict/2 allows BEAM memory exhaustion via unbounded output buffer
- Exploited
- No known exploitation
- Fix
- Fixed in 1.2.5
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 1.2.5.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 17/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
The ezstd Erlang library, in versions before 1.2.5, can be made to exhaust memory and crash the whole Erlang VM through its dictionary decompression function, ezstd:decompress_using_ddict/2. A local attacker who can supply a crafted zstd frame, without logging in or any user action, can trigger a very large allocation from a small input, and because it happens inside a NIF the operating system terminates the entire node.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original 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.
cve.now Index
- Exploitation0/40No signal
- Exposure?/25Unknown. No advisory context yet
- Reach10/20Affects Hex packages
- Severity6.9/10CVSS 6.9
- No patch0/5No signal
What would change the score
- Would score about 72 if added to CISA KEV
- Would score about 67 if CISA's SSVC rates exploitation active
- Would score about 39 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 1.2.5.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- ezstdHex
From 1.0.5 · fixed in 1.2.5
- silviucpp/ezstd
Version range not reported
- ezstdHex
From 1.0.5 · fixed in 1.2.5
Evidence 5
- Patch
- Repository
- Repository
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-119434
Is CVE-2026-119434 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-119434?
ezstd (Hex): from 1.0.5 before 1.2.5. ezstd (Hex): from 1.0.5 before 1.2.5.Source: cve.now feed data
How do I fix CVE-2026-119434?
Upgrade to a fixed version: 1.2.5.Source: cve.now feed data