adm-zip vulnerabilities

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.

adm-zip 0.5.9 through 0.6.0 follows symbolic links at the extraction destination. Utils.sanitize enforces containment by comparing only the string form of an archive entry name against the resolved extraction root, and Utils.writeFileTo opens the computed destination with fs.openSync(path, "w", 0o666), which resolves symbolic links and carries neither O_NOFOLLOW nor a pre-write fs.lstatSync check. When a path component at the destination already exists as a symbolic link pointing outside the extraction root, extractAllTo, extractAllToAsync and extractEntryTo write the entry contents through that link and then chmod its target, placing attacker-controlled content in a file outside the root without any traversal sequence appearing in the archive. Reaching the write requires overwrite to be enabled, because the preceding fs.existsSync check also resolves the link and otherwise declines.

The adm-zip library before version 0.5.18 is vulnerable to denial of service via a crafted ZIP file with a manipulated uncompressed size header field. An attacker can create a small ZIP file (about 120 bytes) declaring an uncompressed size of 4 GB, leading to memory allocation amplification of over 33 million to 1, causing a process crash.