## Summaryadm-zip versions 0.5.14 through 0.6.0 can be forced to skip zlib decompression output limits when ZIP entries declare an attacker-controlled uncompressed size of 0, enabling memory exhaustion and denial of service. The issue is tracked as CVE-2026-92000 (CWE-409).
## Technical Details
The fix for a prior issue (CVE-2026-39244) caps zlib output using maxOutputLength: expectedLength, where expectedLength is read from the ZIP entry’s declared uncompressed-size header field (local/central directory copies, CENLEN/LOCLEN).
However, the cap is only applied when expectedLength > 0:
- When the declared uncompressed-size is exactly 0, the condition fails and no maxOutputLength option is passed to zlib.
- Node’s zlib then falls back to its internal default limit (several GB), allowing a small, highly-compressible payload to decompress to a very large in-memory buffer.
The advisory notes CRC validation still passes because CRC is computed over the real decompressed output rather than the declared size.
## Affected
- adm-zip (npm): versions 0.5.14 through 0.6.0
## Impact
- Denial of service via memory exhaustion when an attacker supplies a crafted ZIP archive over the network.
- Attack prerequisites: attacker must be able to provide or influence ZIP data processed by the application (no authentication required per CVSS vector).
## Mitigation
1. Upgrade adm-zip to a version that includes the corrected decompression output limiting behavior (the advisory references the shipped fix logic and the expectedLength > 0 bypass).
2. If upgrading is not immediately possible, avoid processing untrusted ZIPs with AdmZip(buffer) / getEntries()[i].getData() / extractAllTo / readAsText on attacker-controlled content.
3. Add application-level safeguards: reject ZIP entries whose declared uncompressed size is 0 (or enforce a strict maximum decompressed size before decompression).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-409