{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-119434", "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "state": "PUBLISHED", "assignerShortName": "EEF", "dateReserved": "2026-10-30T10:30:01.015Z", "datePublished": "2026-11-05T20:15:56.311Z", "dateUpdated": "2026-11-05T20:45:33.490Z"}, "containers": {"cna": {"affected": [{"collectionURL": "https://repo.hex.pm", "cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["ezstd_nif", "ezstd"], "packageName": "ezstd", "packageURL": "pkg:hex/ezstd", "product": "ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "versions": [{"lessThan": "1.2.5", "status": "affected", "version": "1.0.5", "versionType": "semver"}]}, {"collectionURL": "https://github.com", "cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["ezstd_nif", "ezstd"], "packageName": "silviucpp/ezstd", "packageURL": "pkg:github/silviucpp/ezstd", "product": "ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "versions": [{"lessThan": "e34f4a4f6dc18d990d1cece2d5fceef8e934a195", "status": "affected", "version": "6730128b1d35eca02a2028671421471ff651f423", "versionType": "git"}]}], "cpeApplicability": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*", "versionEndExcluding": "1.2.5", "versionStartIncluding": "1.0.5", "vulnerable": true}], "negate": false, "operator": "OR"}], "operator": "AND"}], "credits": [{"lang": "en", "type": "finder", "value": "Oz Kaiser"}, {"lang": "en", "type": "reporter", "value": "Oz Kaiser"}, {"lang": "en", "type": "remediation developer", "value": "Silviu Caragea"}, {"lang": "en", "type": "coordinator", "value": "Jonatan M\u00e4nnchen / EEF"}], "dateAssigned": "2026-11-04T17:02:50.000Z", "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to <code>ezstd:decompress_using_ddict/2</code> to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.</p>\n<p><code>zstd_nif_decompress_using_ddict</code> in <code>c_src/ezstd_nif.cc</code> reads the frame's declared content size with <code>ZSTD_getFrameContentSize</code> and passes it directly to <code>enif_make_new_binary</code>, without the 1 GiB <code>MAX_BUFFER_SIZE</code> check that <code>ezstd:decompress/1</code> applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by <code>ezstd:decompress/1</code> 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.</p>\n<p>This issue affects ezstd: from 1.0.5 before 1.2.5.</p>"}, {"base64": false, "type": "text/markdown", "value": "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.\n\n`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.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5."}], "value": "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.\n\nzstd_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.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5."}], "impacts": [{"capecId": "CAPEC-130", "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor.</p>"}, {"base64": false, "type": "text/markdown", "value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor."}], "value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor."}]}], "metrics": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "NONE", "attackVector": "LOCAL", "baseScore": 6.9, "baseSeverity": "MEDIUM", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N", "version": "4.0", "vulnAvailabilityImpact": "HIGH", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-409", "description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "shortName": "EEF", "dateUpdated": "2026-11-05T20:15:56.311Z"}, "references": [{"name": "ezstd v1.2.5 release notes", "tags": ["release-notes", "related"], "url": "https://github.com/silviucpp/ezstd/releases/tag/v1.2.5"}, {"name": "EEF CNA record for CVE-2026-119434", "tags": ["related", "third-party-advisory"], "url": "https://cna.erlef.org/cves/CVE-2026-119434.html"}, {"name": "OSV record EEF-CVE-2026-119434", "tags": ["related"], "url": "https://osv.dev/vulnerability/EEF-CVE-2026-119434"}, {"name": "Introducing commit 6730128 in silviucpp/ezstd", "tags": ["related"], "url": "https://github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423"}, {"name": "Fix commit e34f4a4 in silviucpp/ezstd", "tags": ["patch"], "url": "https://github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195"}], "source": {"discovery": "EXTERNAL"}, "title": "Decompression bomb in ezstd:decompress_using_ddict/2 allows BEAM memory exhaustion via unbounded output buffer", "workarounds": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>Replace calls to <code>ezstd:decompress_using_ddict/2</code> with the streaming API: create a context with <code>ezstd:create_decompression_context/1</code> using a small output buffer, attach the dictionary with <code>ezstd:select_ddict/2</code>, and decompress with <code>ezstd:decompress_streaming/2</code>. The streaming path decompresses into the caller-sized buffer and gives up with <code>{error, decompressor_stuck}</code> after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload.</p>"}, {"base64": false, "type": "text/markdown", "value": "Replace calls to `ezstd:decompress_using_ddict/2` with the streaming API: create a context with `ezstd:create_decompression_context/1` using a small output buffer, attach the dictionary with `ezstd:select_ddict/2`, and decompress with `ezstd:decompress_streaming/2`. The streaming path decompresses into the caller-sized buffer and gives up with `{error, decompressor_stuck}` after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload."}], "value": "Replace calls to ezstd:decompress_using_ddict/2 with the streaming API: create a context with ezstd:create_decompression_context/1 using a small output buffer, attach the dictionary with ezstd:select_ddict/2, and decompress with ezstd:decompress_streaming/2. The streaming path decompresses into the caller-sized buffer and gives up with {error, decompressor_stuck} after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload."}], "x_proofOfConcept": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<ol>\n<li>Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.</li>\n<li>Create any decompression dictionary with <code>ezstd:create_ddict/1</code>; its content does not matter because the frame carries no dictionary ID.</li>\n<li>Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header <code>0x02 0x00 0x10</code> followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.</li>\n<li>Call <code>ezstd:decompress/1</code> on the frame: it returns <code>{error, &lt;&lt;\"frame too large or invalid\"&gt;&gt;}</code>.</li>\n<li>Call <code>ezstd:decompress_using_ddict/2</code> on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).</li>\n<li>Repeat on 1.2.5: the call returns <code>{error, &lt;&lt;\"frame too large or invalid\"&gt;&gt;}</code> and the VM continues.</li>\n</ol>"}, {"base64": false, "type": "text/markdown", "value": "1. Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n2. Create any decompression dictionary with `ezstd:create_ddict/1`; its content does not matter because the frame carries no dictionary ID.\n3. Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header `0x02 0x00 0x10` followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n4. Call `ezstd:decompress/1` on the frame: it returns `{error, <<\"frame too large or invalid\">>}`.\n5. Call `ezstd:decompress_using_ddict/2` on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n6. Repeat on 1.2.5: the call returns `{error, <<\"frame too large or invalid\">>}` and the VM continues."}], "value": "* Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n* Create any decompression dictionary with ezstd:create_ddict/1; its content does not matter because the frame carries no dictionary ID.\n* Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header 0x02 0x00 0x10 followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n* Call ezstd:decompress/1 on the frame: it returns {error, <<\"frame too large or invalid\">>}.\n* Call ezstd:decompress_using_ddict/2 on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n* Repeat on 1.2.5: the call returns {error, <<\"frame too large or invalid\">>} and the VM continues."}], "x_technicalAnalysis": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p><strong>1. Declared size is attacker controlled.</strong> A zstd frame header carries an optional Frame Content Size field. <code>zstd_nif_decompress_using_ddict</code> in <code>c_src/ezstd_nif.cc</code> reads it with <code>ZSTD_getFrameContentSize</code> and rejects only the two sentinel values <code>ZSTD_CONTENTSIZE_UNKNOWN</code> and <code>ZSTD_CONTENTSIZE_ERROR</code>.</p>\n<p><strong>2. Unbounded allocation.</strong> The size is passed directly to <code>enif_make_new_binary</code>, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling <code>zstd_nif_decompress</code> rejects any declared size above <code>MAX_BUFFER_SIZE</code> (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.</p>\n<p><strong>3. Amplification.</strong> A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. <code>ZSTD_decompress_usingDDict</code> then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception.</p>"}, {"base64": false, "type": "text/markdown", "value": "**1. Declared size is attacker controlled.** A zstd frame header carries an optional Frame Content Size field. `zstd_nif_decompress_using_ddict` in `c_src/ezstd_nif.cc` reads it with `ZSTD_getFrameContentSize` and rejects only the two sentinel values `ZSTD_CONTENTSIZE_UNKNOWN` and `ZSTD_CONTENTSIZE_ERROR`.\n\n**2. Unbounded allocation.** The size is passed directly to `enif_make_new_binary`, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling `zstd_nif_decompress` rejects any declared size above `MAX_BUFFER_SIZE` (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n**3. Amplification.** A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. `ZSTD_decompress_usingDDict` then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception."}], "value": "1. Declared size is attacker controlled. A zstd frame header carries an optional Frame Content Size field. zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads it with ZSTD_getFrameContentSize and rejects only the two sentinel values ZSTD_CONTENTSIZE_UNKNOWN and ZSTD_CONTENTSIZE_ERROR.\n\n2. Unbounded allocation. The size is passed directly to enif_make_new_binary, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling zstd_nif_decompress rejects any declared size above MAX_BUFFER_SIZE (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n3. Amplification. A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. ZSTD_decompress_usingDDict then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception."}]}, "adp": [{"metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.2, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"timestamp": "2026-11-05T20:45:27.204341Z", "id": "CVE-2026-119434", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-05T20:45:33.490Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.2, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}}, {"other": {"type": "ssvc", "content": {"id": "CVE-2026-119434", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-11-05T20:45:27.204341Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-05T20:45:20.867Z"}}], "cna": {"title": "Decompression bomb in ezstd:decompress_using_ddict/2 allows BEAM memory exhaustion via unbounded output buffer", "source": {"discovery": "EXTERNAL"}, "credits": [{"lang": "en", "type": "finder", "value": "Oz Kaiser"}, {"lang": "en", "type": "reporter", "value": "Oz Kaiser"}, {"lang": "en", "type": "remediation developer", "value": "Silviu Caragea"}, {"lang": "en", "type": "coordinator", "value": "Jonatan M\u00e4nnchen / EEF"}], "impacts": [{"capecId": "CAPEC-130", "descriptions": [{"lang": "en", "value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor.", "supportingMedia": [{"type": "text/html", "value": "<p>An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor.</p>", "base64": false}, {"type": "text/markdown", "value": "An attacker who can submit a zstd frame to a service that decompresses it with a fixed dictionary can crash the entire Erlang VM with a single request of about 65 KiB. Every application and process hosted in that VM is taken down, not only the one that called the decompressor.", "base64": false}]}]}], "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 6.9, "Automatable": "NOT_DEFINED", "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "HIGH", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "modules": ["ezstd_nif", "ezstd"], "product": "ezstd", "versions": [{"status": "affected", "version": "1.0.5", "lessThan": "1.2.5", "versionType": "semver"}], "packageURL": "pkg:hex/ezstd", "packageName": "ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "collectionURL": "https://repo.hex.pm", "defaultStatus": "unaffected", "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}]}, {"cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "modules": ["ezstd_nif", "ezstd"], "product": "ezstd", "versions": [{"status": "affected", "version": "6730128b1d35eca02a2028671421471ff651f423", "lessThan": "e34f4a4f6dc18d990d1cece2d5fceef8e934a195", "versionType": "git"}], "packageURL": "pkg:github/silviucpp/ezstd", "packageName": "silviucpp/ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "collectionURL": "https://github.com", "defaultStatus": "unaffected", "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}]}], "references": [{"url": "https://github.com/silviucpp/ezstd/releases/tag/v1.2.5", "name": "ezstd v1.2.5 release notes", "tags": ["release-notes", "related"]}, {"url": "https://cna.erlef.org/cves/CVE-2026-119434.html", "name": "EEF CNA record for CVE-2026-119434", "tags": ["related", "third-party-advisory"]}, {"url": "https://osv.dev/vulnerability/EEF-CVE-2026-119434", "name": "OSV record EEF-CVE-2026-119434", "tags": ["related"]}, {"url": "https://github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423", "name": "Introducing commit 6730128 in silviucpp/ezstd", "tags": ["related"]}, {"url": "https://github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195", "name": "Fix commit e34f4a4 in silviucpp/ezstd", "tags": ["patch"]}], "workarounds": [{"lang": "en", "value": "Replace calls to ezstd:decompress_using_ddict/2 with the streaming API: create a context with ezstd:create_decompression_context/1 using a small output buffer, attach the dictionary with ezstd:select_ddict/2, and decompress with ezstd:decompress_streaming/2. The streaming path decompresses into the caller-sized buffer and gives up with {error, decompressor_stuck} after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload.", "supportingMedia": [{"type": "text/html", "value": "<p>Replace calls to <code>ezstd:decompress_using_ddict/2</code> with the streaming API: create a context with <code>ezstd:create_decompression_context/1</code> using a small output buffer, attach the dictionary with <code>ezstd:select_ddict/2</code>, and decompress with <code>ezstd:decompress_streaming/2</code>. The streaming path decompresses into the caller-sized buffer and gives up with <code>{error, decompressor_stuck}</code> after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload.</p>", "base64": false}, {"type": "text/markdown", "value": "Replace calls to `ezstd:decompress_using_ddict/2` with the streaming API: create a context with `ezstd:create_decompression_context/1` using a small output buffer, attach the dictionary with `ezstd:select_ddict/2`, and decompress with `ezstd:decompress_streaming/2`. The streaming path decompresses into the caller-sized buffer and gives up with `{error, decompressor_stuck}` after 1000 chunks, so a 64 KiB buffer caps a single call at 64 MiB of output. Treat that error as a rejected input. Legitimate frames whose output exceeds 1000 times the buffer size fail the same way, so size the buffer for the largest expected payload.", "base64": false}]}], "dateAssigned": "2026-11-04T17:02:50.000Z", "descriptions": [{"lang": "en", "value": "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.\n\nzstd_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.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5.", "supportingMedia": [{"type": "text/html", "value": "<p>Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in silviucpp ezstd allows an attacker who supplies a zstd frame to <code>ezstd:decompress_using_ddict/2</code> to exhaust memory and terminate the Erlang VM via a small frame that declares a very large content size.</p>\n<p><code>zstd_nif_decompress_using_ddict</code> in <code>c_src/ezstd_nif.cc</code> reads the frame's declared content size with <code>ZSTD_getFrameContentSize</code> and passes it directly to <code>enif_make_new_binary</code>, without the 1 GiB <code>MAX_BUFFER_SIZE</code> check that <code>ezstd:decompress/1</code> applies before allocating. A valid 65,550-byte frame of RLE blocks declaring 2 GiB is rejected by <code>ezstd:decompress/1</code> 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.</p>\n<p>This issue affects ezstd: from 1.0.5 before 1.2.5.</p>", "base64": false}, {"type": "text/markdown", "value": "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.\n\n`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.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5.", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-409", "description": "CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)"}]}], "cpeApplicability": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*", "vulnerable": true, "versionEndExcluding": "1.2.5", "versionStartIncluding": "1.0.5"}], "operator": "OR"}], "operator": "AND"}], "providerMetadata": {"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "shortName": "EEF", "dateUpdated": "2026-11-05T20:15:56.311Z"}, "x_proofOfConcept": [{"lang": "en", "value": "* Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n* Create any decompression dictionary with ezstd:create_ddict/1; its content does not matter because the frame carries no dictionary ID.\n* Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header 0x02 0x00 0x10 followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n* Call ezstd:decompress/1 on the frame: it returns {error, <<\"frame too large or invalid\">>}.\n* Call ezstd:decompress_using_ddict/2 on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n* Repeat on 1.2.5: the call returns {error, <<\"frame too large or invalid\">>} and the VM continues.", "supportingMedia": [{"type": "text/html", "value": "<ol>\n<li>Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.</li>\n<li>Create any decompression dictionary with <code>ezstd:create_ddict/1</code>; its content does not matter because the frame carries no dictionary ID.</li>\n<li>Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header <code>0x02 0x00 0x10</code> followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.</li>\n<li>Call <code>ezstd:decompress/1</code> on the frame: it returns <code>{error, &lt;&lt;\"frame too large or invalid\"&gt;&gt;}</code>.</li>\n<li>Call <code>ezstd:decompress_using_ddict/2</code> on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).</li>\n<li>Repeat on 1.2.5: the call returns <code>{error, &lt;&lt;\"frame too large or invalid\"&gt;&gt;}</code> and the VM continues.</li>\n</ol>", "base64": false}, {"type": "text/markdown", "value": "1. Build ezstd 1.2.4 and start a VM under an external memory limit, for example a container limited to 256 MiB.\n2. Create any decompression dictionary with `ezstd:create_ddict/1`; its content does not matter because the frame carries no dictionary ID.\n3. Construct a zstd frame: the magic number, a frame header descriptor selecting an 8-byte content size, a window descriptor, a little-endian content size of 2 GiB, then 16,383 RLE blocks of 128 KiB each (block header `0x02 0x00 0x10` followed by one payload byte) and a final RLE block with the last-block bit set. The frame is 65,550 bytes.\n4. Call `ezstd:decompress/1` on the frame: it returns `{error, <<\"frame too large or invalid\">>}`.\n5. Call `ezstd:decompress_using_ddict/2` on the same frame with the dictionary: the VM is killed by the operating system (exit status 137).\n6. Repeat on 1.2.5: the call returns `{error, <<\"frame too large or invalid\">>}` and the VM continues.", "base64": false}]}], "x_technicalAnalysis": [{"lang": "en", "value": "1. Declared size is attacker controlled. A zstd frame header carries an optional Frame Content Size field. zstd_nif_decompress_using_ddict in c_src/ezstd_nif.cc reads it with ZSTD_getFrameContentSize and rejects only the two sentinel values ZSTD_CONTENTSIZE_UNKNOWN and ZSTD_CONTENTSIZE_ERROR.\n\n2. Unbounded allocation. The size is passed directly to enif_make_new_binary, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling zstd_nif_decompress rejects any declared size above MAX_BUFFER_SIZE (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n3. Amplification. A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. ZSTD_decompress_usingDDict then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception.", "supportingMedia": [{"type": "text/html", "value": "<p><strong>1. Declared size is attacker controlled.</strong> A zstd frame header carries an optional Frame Content Size field. <code>zstd_nif_decompress_using_ddict</code> in <code>c_src/ezstd_nif.cc</code> reads it with <code>ZSTD_getFrameContentSize</code> and rejects only the two sentinel values <code>ZSTD_CONTENTSIZE_UNKNOWN</code> and <code>ZSTD_CONTENTSIZE_ERROR</code>.</p>\n<p><strong>2. Unbounded allocation.</strong> The size is passed directly to <code>enif_make_new_binary</code>, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling <code>zstd_nif_decompress</code> rejects any declared size above <code>MAX_BUFFER_SIZE</code> (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.</p>\n<p><strong>3. Amplification.</strong> A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. <code>ZSTD_decompress_usingDDict</code> then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception.</p>", "base64": false}, {"type": "text/markdown", "value": "**1. Declared size is attacker controlled.** A zstd frame header carries an optional Frame Content Size field. `zstd_nif_decompress_using_ddict` in `c_src/ezstd_nif.cc` reads it with `ZSTD_getFrameContentSize` and rejects only the two sentinel values `ZSTD_CONTENTSIZE_UNKNOWN` and `ZSTD_CONTENTSIZE_ERROR`.\n\n**2. Unbounded allocation.** The size is passed directly to `enif_make_new_binary`, so a frame declaring 2 GiB makes the NIF request a 2 GiB binary. The sibling `zstd_nif_decompress` rejects any declared size above `MAX_BUFFER_SIZE` (1 GiB) before allocating; the dictionary path omitted that check from the commit that introduced it.\n\n**3. Amplification.** A frame built from RLE blocks, each encoding 128 KiB of a repeated byte in four bytes, declares and genuinely decompresses to 2 GiB from 65,550 bytes of input, a ratio of about 32,760:1. `ZSTD_decompress_usingDDict` then fills the buffer. Because this happens inside a NIF, exceeding the memory available to the VM results in the operating system killing the whole BEAM process rather than an Erlang-level exception.", "base64": false}]}]}}, "cveMetadata": {"cveId": "CVE-2026-119434", "state": "PUBLISHED", "dateUpdated": "2026-11-05T20:45:33.490Z", "dateReserved": "2026-10-30T10:30:01.015Z", "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "datePublished": "2026-11-05T20:15:56.311Z", "assignerShortName": "EEF"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"collectionURL": "https://repo.hex.pm", "cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["ezstd_nif", "ezstd"], "packageName": "ezstd", "packageURL": "pkg:hex/ezstd", "product": "ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "versions": [{"lessThan": "1.2.5", "status": "affected", "version": "1.0.5", "versionType": "semver"}]}, {"collectionURL": "https://github.com", "cpes": ["cpe:2.3:a:silviucpp:ezstd:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "modules": ["ezstd_nif", "ezstd"], "packageName": "silviucpp/ezstd", "packageURL": "pkg:github/silviucpp/ezstd", "product": "ezstd", "programFiles": ["c_src/ezstd_nif.cc", "src/ezstd_nif.erl", "src/ezstd.erl"], "programRoutines": [{"name": "zstd_nif_decompress_using_ddict"}, {"name": "ezstd_nif:decompress_using_ddict/2"}, {"name": "ezstd:decompress_using_ddict/2"}], "repo": "https://github.com/silviucpp/ezstd", "vendor": "silviucpp", "versions": [{"lessThan": "e34f4a4f6dc18d990d1cece2d5fceef8e934a195", "status": "affected", "version": "6730128b1d35eca02a2028671421471ff651f423", "versionType": "git"}]}], "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "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.\n\nzstd_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.\n\nThis issue affects ezstd: from 1.0.5 before 1.2.5."}], "id": "CVE-2026-119434", "lastModified": "2026-11-05T21:18:41.210", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 6.2, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 2.5, "impactScore": 3.6, "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "NONE", "attackVector": "LOCAL", "availabilityRequirement": "NOT_DEFINED", "baseScore": 6.9, "baseSeverity": "MEDIUM", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "version": "4.0", "vulnAvailabilityImpact": "HIGH", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-119434", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-11-05T20:45:27.204341Z", "version": "2.0.3"}}]}, "published": "2026-11-05T21:18:41.210", "references": [{"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://cna.erlef.org/cves/CVE-2026-119434.html"}, {"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423"}, {"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195"}, {"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://github.com/silviucpp/ezstd/releases/tag/v1.2.5"}, {"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://osv.dev/vulnerability/EEF-CVE-2026-119434"}], "sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-409"}], "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "type": "Secondary"}]}

{"bugzilla": {"description": "ezstd: ezstd: Denial of Service via memory exhaustion during decompression", "id": "2567737", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2567737"}, "csaw": false, "cvss3": {"cvss3_base_score": "6.2", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-409", "details": ["A flaw was found in ezstd. An attacker can cause a Denial of Service (DoS) by providing a specially crafted compressed data frame that declares an excessively large uncompressed size. When decompressing the data using a dictionary, ezstd fails to enforce memory buffer limits, leading to memory exhaustion that causes the operating system to terminate the Erlang virtual machine."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."}, "name": "CVE-2026-119434", "public_date": "2026-11-05T20:15:56Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-119434\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-119434\nhttps://cna.erlef.org/cves/CVE-2026-119434.html\nhttps://github.com/silviucpp/ezstd/commit/6730128b1d35eca02a2028671421471ff651f423\nhttps://github.com/silviucpp/ezstd/commit/e34f4a4f6dc18d990d1cece2d5fceef8e934a195\nhttps://github.com/silviucpp/ezstd/releases/tag/v1.2.5\nhttps://osv.dev/vulnerability/EEF-CVE-2026-119434"], "statement": "This vulnerability is rated as Moderate impact for Red Hat environments because the blast radius is confined to a denial of service against the host Erlang runtime, with no compromise of system confidentiality or data integrity. In typical Red Hat deployments, ezstd is not included in default platform installations or standard system services, restricting potential exposure to customized Erlang applications. Furthermore, triggering the crash requires the application to actively accept and decompress untrusted input using dictionary decompression routines.", "threat_severity": "Moderate"}