{"id":"CVE-2026-92000","aliases":["CLSA-2026-1790718594","CLSA-2026-1791979104","CLSA-2026-1791979197","CLSA-2026-1791980535","CLSA-2026-1791981819","CLSA-2026-1791989313","CLSA-2026-1793986304","EUVD-2026-80001","GHSA-8238-w5pm-2374","GHSA-c6fg-446q-cg94","GHSA-ffxc-vw9f-x2cp","GHSA-rcw4-f5rp-g42v","ROOT-APP-NPM-GHSA-rcw4-f5rp-g42v"],"status":"published","title":"adm-zip 0.5.14 through 0.6.0 Denial of Service via Zero Declared Uncompressed Size","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","severity":{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00684,"percentile":0.5301,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400","CWE-409","CWE-770"],"published":"2026-09-15T20:56:45Z","modified":"2026-11-07T01:00:02Z","fixes":[{"ecosystem":"npm","package":"adm-zip","fixed_in":["0.6.1"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"adm-zip","fixed_in":["0.5.18-tuxcare.4","0.4.4-tuxcare.5","0.4.7-tuxcare.4","0.4.16-tuxcare.3"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"adm-zip","fixed_in":["0.6.0-aikido.2","0.6.0-aikido.3","0.5.10-aikido.4","0.5.10-aikido.5","0.5.9-aikido.2","0.5.18-aikido.3","0.5.9-aikido.3"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@rootio/adm-zip","fixed_in":["0.6.0-root.io.2","0.6.0-root.io.3","0.5.10-root.io.4","0.5.10-root.io.5","0.5.9-root.io.2","0.5.18-root.io.3","0.5.9-root.io.3"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.6.0"},{"fixed":"0.6.1"}]}]},{"source":"ghsa","ecosystem":"npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.6.0"},{"fixed":"0.6.1"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.5.18-tuxcare.0"},{"fixed":"0.5.18-tuxcare.4"}]}],"versions":["0.5.18","0.5.18-tuxcare.1","0.5.18-tuxcare.2","0.5.18-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.4.4-tuxcare.0"},{"fixed":"0.4.4-tuxcare.5"}]}],"versions":["0.4.4","0.4.4-tuxcare.1","0.4.4-tuxcare.2","0.4.4-tuxcare.3","0.4.4-tuxcare.4"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.4.7-tuxcare.0"},{"fixed":"0.4.7-tuxcare.4"}]}],"versions":["0.4.7","0.4.7-tuxcare.1","0.4.7-tuxcare.2","0.4.7-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.4.16-tuxcare.0"},{"fixed":"0.4.16-tuxcare.3"}]}],"versions":["0.4.16","0.4.16-tuxcare.1","0.4.16-tuxcare.2"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.5.10-tuxcare.0"},{"fixed":"0.5.10-tuxcare.5"}]}],"versions":["0.5.10","0.5.10-tuxcare.1","0.5.10-tuxcare.2","0.5.10-tuxcare.3","0.5.10-tuxcare.4"],"bundled":2},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.5.12-tuxcare.0"},{"fixed":"0.5.12-tuxcare.4"}]}],"versions":["0.5.12","0.5.12-tuxcare.1","0.5.12-tuxcare.2","0.5.12-tuxcare.3"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.5.17-tuxcare.0"},{"fixed":"0.5.17-tuxcare.5"}]}],"versions":["0.5.17","0.5.17-tuxcare.1","0.5.17-tuxcare.2","0.5.17-tuxcare.3","0.5.17-tuxcare.4"],"bundled":2},{"source":"osv","ecosystem":"npm","package":"adm-zip","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.6.1"}]}]},{"source":"osv","ecosystem":"npm","package":"adm-zip","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.6.1"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.6.0-aikido.2"},{"fixed":"0.6.0-aikido.3"},{"fixed":"0.5.10-aikido.4"},{"fixed":"0.5.10-aikido.5"},{"fixed":"0.5.9-aikido.2"},{"fixed":"0.5.18-aikido.3"},{"fixed":"0.5.9-aikido.3"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@rootio/adm-zip","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.6.0-root.io.2"},{"fixed":"0.6.0-root.io.3"},{"fixed":"0.5.10-root.io.4"},{"fixed":"0.5.10-root.io.5"},{"fixed":"0.5.9-root.io.2"},{"fixed":"0.5.18-root.io.3"},{"fixed":"0.5.9-root.io.3"}]}]}],"products":[{"vendor":"cthackers","product":"adm-zip"},{"vendor":"node.js","product":"adm-zip"}],"references":[{"url":"https://github.com/cthackers/adm-zip/security/advisories/GHSA-rcw4-f5rp-g42v","tags":["vendor-advisory","advisory","web"]},{"url":"https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6","tags":["patch","fix","web"]},{"url":"https://github.com/cthackers/adm-zip/commit/8bc411184de1b5ca28138c53074fb61119994dde","tags":["technical-description","patch","fix"]},{"url":"https://github.com/cthackers/adm-zip/blob/v0.6.0/methods/inflater.js","tags":["technical-description","article"]},{"url":"https://github.com/cthackers/adm-zip","tags":["product","package"]},{"url":"https://www.vulncheck.com/advisories/adm-zip-0.5.14-through-0.6.0-denial-of-service-via-zero-declared-uncompressed-size","tags":["third-party-advisory","advisory"]},{"url":"https://github.com/cthackers/adm-zip/security/advisories/GHSA-c6fg-446q-cg94","tags":["web"]},{"url":"https://github.com/cthackers/adm-zip/releases/tag/v0.6.1","tags":["web"]},{"url":"https://github.com/advisories/GHSA-c6fg-446q-cg94"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92000","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-ffxc-vw9f-x2cp"},{"url":"https://github.com/advisories/GHSA-rcw4-f5rp-g42v"},{"url":"https://www.npmjs.com/package/adm-zip","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92000.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-92000","title":"adm-zip 0.5.14 through 0.6.0 Denial of Service via Zero Declared Uncompressed Size","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","status":"published","published":"2026-09-15T20:56:45.78Z","modified":"2026-09-24T14:22:38.58Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T13:48:24.536396Z"}],"euvd":[{"id":"EUVD-2026-80001","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","status":"published","published":"2026-09-15T20:56:45Z","modified":"2026-09-24T14:22:38Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T17:27:57.035497Z"}],"ghsa":[{"id":"GHSA-c6fg-446q-cg94","title":"adm-zip: getDataAsync() bypasses the maxOutputLength size guard enforced by the synchronous getData() path","description":"### Summary\nadm-zip enforces a `maxOutputLength` guard against decompression bombs on its synchronous `getData()` path, but the equivalent asynchronous `getDataAsync()` path does not enforce it — it accumulates and returns the entire decompressed output regardless of the entry's declared size. An application that checks an entry's declared size before deciding to process it, then reads the entry via `getDataAsync()` (a completely ordinary, often-recommended choice for I/O in Node.js), gets none of the protection it believes it has.\n\n\n### Details\n\n- `methods/inflater.js:3-10` passes `{maxOutputLength: expectedLength}` to `inflateRawSync`, which Node enforces.\n- `methods/inflater.js:12-31` passes the same option to `createInflateRaw` but never enforces it on the streaming path — it just accumulates every chunk and allocates a final Buffer of whatever size resulted.\n\n\n### PoC\n\n```js\nconst AdmZip = require('adm-zip');\nconst zip = new AdmZip();\nzip.addFile('p', Buffer.alloc(64 * 1024 * 1024, 0x41)); // 64 MiB\nconst raw = Buffer.from(zip.toBuffer());\n// patch the local + central declared uncompressed size to 1 byte\nraw.writeUInt32LE(1, localHeaderSizeOffset);\nraw.writeUInt32LE(1, centralHeaderSizeOffset);\nconst entry = new AdmZip(raw).getEntry('p');\n\nentry.getData();\n// throws: ERR_BUFFER_TOO_LARGE: Cannot create a Buffer larger than 1 bytes\n\nentry.getDataAsync((data, error) =\u003e { ... });\n// returns the full 67,108,864-byte buffer, error is undefined\n```\n\n### Impact\nAn application that validates a declared size before reading an entry, then uses the async API, gets no protection against a high-ratio DEFLATE payload. Repeated or larger requests could contribute to memory exhaustion.","status":"published","published":"2026-09-29T23:10:32Z","modified":"2026-09-29T23:10:35Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T14:41:22.654187Z"},{"id":"GHSA-ffxc-vw9f-x2cp","title":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP...","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","status":"published","published":"2026-09-15T21:33:05Z","modified":"2026-09-15T21:33:15Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/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","level":"high"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:11:56.361668Z"},{"id":"GHSA-rcw4-f5rp-g42v","title":"adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0","description":"**Affected package:** adm-zip (npm)\n**Affected version:** 0.6.0\n\n## Summary\n\nThe fix shipped for CVE-2026-39244 (`methods/inflater.js`) caps zlib's decompression output via `maxOutputLength: expectedLength`, where `expectedLength` is read directly from the ZIP entry's attacker-controlled \"uncompressed size\" header field (`CENLEN`/`LOCLEN`). This cap is only applied when `expectedLength \u003e 0`:\n\n```js\nconst option = version \u003e= 15 \u0026\u0026 expectedLength \u003e 0 ? { maxOutputLength: expectedLength } : {};\nreturn zlib.inflateRawSync(inbuf, option);\n```\n\nIf an attacker sets the declared uncompressed-size field to exactly **0**, this condition is false, `option` becomes `{}`, and no output cap is passed to zlib at all. Node then falls back to zlib's own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.\n\n## Steps to Reproduce\n\n1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio).\n2. Patch the entry's declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size.\n3. Load the archive with `new AdmZip(buffer)` and call `.getEntries()[0].getData()` (or `readFile`/`readAsText`/`extractAllTo`/etc. -- all share the same code path).\n4. Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws `Cannot create a Buffer larger than N bytes`.\n\n## Proof of Concept\n\nAttached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs:\n\n- **Control** (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when `expectedLength \u003e 0`.\n- **Bypass** (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction.\n\nVerified reproducible across 3 independent runs.\n\n## Impact\n\nAny application that calls adm-zip's read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib's own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM.\n\n## Suggested Fix\n\nApply `maxOutputLength` unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it's 0), and/or add an independent compression-ratio check that doesn't rely solely on the attacker-supplied size field.","status":"published","published":"2026-09-29T18:25:20Z","modified":"2026-09-29T18:25:21Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:41:22.654187Z"}],"nvd":[{"id":"CVE-2026-92000","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","status":"published","published":"2026-09-15T21:16:49.167Z","modified":"2026-09-24T21:08:55.03Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/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","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:12:48.287983Z"}],"osv":[{"id":"CVE-2026-92000","title":"adm-zip 0.5.14 through 0.6.0 Denial of Service via Zero Declared Uncompressed Size","description":"adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service.","status":"published","published":"2026-09-15T20:56:45.78Z","modified":"2026-10-28T02:31:04.565774189Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:45:20.269367Z"},{"id":"GHSA-c6fg-446q-cg94","title":"adm-zip: getDataAsync() bypasses the maxOutputLength size guard enforced by the synchronous getData() path","description":"### Summary\nadm-zip enforces a `maxOutputLength` guard against decompression bombs on its synchronous `getData()` path, but the equivalent asynchronous `getDataAsync()` path does not enforce it — it accumulates and returns the entire decompressed output regardless of the entry's declared size. An application that checks an entry's declared size before deciding to process it, then reads the entry via `getDataAsync()` (a completely ordinary, often-recommended choice for I/O in Node.js), gets none of the protection it believes it has.\n\n\n### Details\n\n- `methods/inflater.js:3-10` passes `{maxOutputLength: expectedLength}` to `inflateRawSync`, which Node enforces.\n- `methods/inflater.js:12-31` passes the same option to `createInflateRaw` but never enforces it on the streaming path — it just accumulates every chunk and allocates a final Buffer of whatever size resulted.\n\n\n### PoC\n\n```js\nconst AdmZip = require('adm-zip');\nconst zip = new AdmZip();\nzip.addFile('p', Buffer.alloc(64 * 1024 * 1024, 0x41)); // 64 MiB\nconst raw = Buffer.from(zip.toBuffer());\n// patch the local + central declared uncompressed size to 1 byte\nraw.writeUInt32LE(1, localHeaderSizeOffset);\nraw.writeUInt32LE(1, centralHeaderSizeOffset);\nconst entry = new AdmZip(raw).getEntry('p');\n\nentry.getData();\n// throws: ERR_BUFFER_TOO_LARGE: Cannot create a Buffer larger than 1 bytes\n\nentry.getDataAsync((data, error) =\u003e { ... });\n// returns the full 67,108,864-byte buffer, error is undefined\n```\n\n### Impact\nAn application that validates a declared size before reading an entry, then uses the async API, gets no protection against a high-ratio DEFLATE payload. Repeated or larger requests could contribute to memory exhaustion.","status":"published","published":"2026-09-29T23:10:32Z","modified":"2026-10-21T10:57:29.375696244Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-400","CWE-770"],"updated_at":"2026-11-02T15:46:44.571161Z"},{"id":"GHSA-rcw4-f5rp-g42v","title":"adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0","description":"**Affected package:** adm-zip (npm)\n**Affected version:** 0.6.0\n\n## Summary\n\nThe fix shipped for CVE-2026-39244 (`methods/inflater.js`) caps zlib's decompression output via `maxOutputLength: expectedLength`, where `expectedLength` is read directly from the ZIP entry's attacker-controlled \"uncompressed size\" header field (`CENLEN`/`LOCLEN`). This cap is only applied when `expectedLength \u003e 0`:\n\n```js\nconst option = version \u003e= 15 \u0026\u0026 expectedLength \u003e 0 ? { maxOutputLength: expectedLength } : {};\nreturn zlib.inflateRawSync(inbuf, option);\n```\n\nIf an attacker sets the declared uncompressed-size field to exactly **0**, this condition is false, `option` becomes `{}`, and no output cap is passed to zlib at all. Node then falls back to zlib's own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently.\n\n## Steps to Reproduce\n\n1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1 theoretical raw-DEFLATE compression ratio).\n2. Patch the entry's declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size.\n3. Load the archive with `new AdmZip(buffer)` and call `.getEntries()[0].getData()` (or `readFile`/`readAsText`/`extractAllTo`/etc. -- all share the same code path).\n4. Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws `Cannot create a Buffer larger than N bytes`.\n\n## Proof of Concept\n\nAttached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs:\n\n- **Control** (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when `expectedLength \u003e 0`.\n- **Bypass** (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction.\n\nVerified reproducible across 3 independent runs.\n\n## Impact\n\nAny application that calls adm-zip's read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib's own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM.\n\n## Suggested Fix\n\nApply `maxOutputLength` unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it's 0), and/or add an independent compression-ratio check that doesn't rely solely on the attacker-supplied size field.","status":"published","published":"2026-09-29T18:25:20Z","modified":"2026-09-29T18:30:41.154879367Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:46:55.877614Z"},{"id":"ROOT-APP-NPM-GHSA-rcw4-f5rp-g42v","title":"GHSA-rcw4-f5rp-g42v in adm-zip - Patched by Root","description":"Root has patched GHSA-rcw4-f5rp-g42v in the adm-zip package for Root:npm. Multiple fixed versions available.","status":"published","published":"2026-11-06T08:25:35Z","modified":"2026-11-06T09:15:03.155789542Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-06T09:36:49.371047Z"},{"id":"CLSA-2026-1790718594","title":"TuxCare security update for adm-zip (1 CVE)","description":"TuxCare rebuilt adm-zip to address 1 CVE. Fixed in 0.5.18-tuxcare.4.","status":"published","published":"2026-09-29T21:49:54Z","modified":"2026-10-15T09:47:57.563472155Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1791979104","title":"TuxCare security update for adm-zip (2 CVEs)","description":"TuxCare rebuilt adm-zip to address 2 CVEs. Fixed in 0.4.4-tuxcare.5.","status":"published","published":"2026-10-14T11:58:24Z","modified":"2026-10-15T09:47:40.742473215Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791979197","title":"TuxCare security update for adm-zip (2 CVEs)","description":"TuxCare rebuilt adm-zip to address 2 CVEs. Fixed in 0.4.7-tuxcare.4.","status":"published","published":"2026-10-14T11:59:57Z","modified":"2026-10-15T09:47:40.636317705Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791980535","title":"TuxCare security update for adm-zip (2 CVEs)","description":"TuxCare rebuilt adm-zip to address 2 CVEs. Fixed in 0.4.16-tuxcare.3.","status":"published","published":"2026-10-14T12:22:15Z","modified":"2026-10-15T09:47:40.643427873Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791981819","title":"TuxCare security update for adm-zip (4 CVEs)","description":"TuxCare rebuilt adm-zip to address 4 CVEs. Fixed in 0.5.10-tuxcare.5.","status":"published","published":"2026-10-14T12:43:39Z","modified":"2026-10-15T09:47:21.171843264Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791989313","title":"TuxCare security update for adm-zip (4 CVEs)","description":"TuxCare rebuilt adm-zip to address 4 CVEs. Fixed in 0.5.12-tuxcare.4.","status":"published","published":"2026-10-14T14:48:33Z","modified":"2026-10-15T09:47:40.490176898Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1793986304","title":"TuxCare security update for adm-zip (2 CVEs)","description":"TuxCare rebuilt adm-zip to address 2 CVEs. Fixed in 0.5.17-tuxcare.5.","status":"published","published":"2026-11-06T18:31:45Z","modified":"2026-11-07T01:00:02.388414455Z","updated_at":"2026-11-07T01:26:17.791146Z"}]}}