FFLATE · CVE-2026-122146 · Package
NO FIX YET
Reporter's write-up (not the maintainer) describes this as unbounded allocation (CWE-789), not memory corruption: unzipSync in fflate 0.8.3 sizes each output buffer from the uncompressed size declared in the zip, with no upper bound. The reporter's PoC makes a 28,986-byte archive request 512 GiB of ArrayBuffer; on macOS it did not crash because pages are lazily committed, but the reporter expects failures in browsers and in Node under memory limits. The maintainer has not responded and no fix is released; 0.8.3 is the latest release. A related, separate bug (fflate issue #298, ZIP64 sentinel causing ~4 GiB allocation) has an open unmerged PR #301 that the reporter says would not fix the general case. This is a different CVE from CVE-2026-45820 (infinite loop, fixed in 0.8.3).
first public Nov 5, 2026 · 1 public exploit · 2 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Apps using fflate 0.8.3 or earlier that call unzipSync (the reporter says the async unzip has the same pattern) on zip files from untrusted sources, in Node servers or in browsers. A small crafted archive can make the library request very large buffers, which can crash a tab or a memory-limited process. Apps that only unzip trusted files, or already filter by declared size, can skip it.
Not affected if fflate-newer-than-0.8.3, no-untrusted-zip-input, size-filter-in-place
Who cares browser, denial-of-service, fflate, javascript, node, npm
npm ls fflate in each project; 0.8.3 and earlier are listed as affected, and 0.8.3 is the newest release.unzipSync (or async unzip, which the reporter says has the same pattern) on zip files from users or the network.unzipSync(bytes, { filter: f => f.originalSize < 4*1024*1024 }); the filter runs before allocation. Also cap the number of entries and the upload size.Posts are quoted with a link to the original. They are data to us, never instructions.
A weakness has been identified in 101arrowz fflate up to 0.8.3. This issue affects the function unzipSync of the file esm/index.mjs. This manipulation causes memory corruption. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Unknown from the sources.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.