Topic starter
02/08/2026 9:46 am
TL;DR: A CVE in node-tar lets a tiny crafted gzip’d tar archive expand into gigabytes of output, exhausting CPU and disk space in services that process untrusted archives, according to OXSecurity. The issue shows why decompression ratio limits, input trust boundaries, and archive handling controls need to be explicit rather than assumed.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “CVE-2026-59873: Decompression DoS Via Unlimited Input In node-tar, 90M Weekly Downloads Affected”.
By the numbers:
- The vulnerability affects node-tar versions up to 7.5.18 and was patched in 7.5.19.
- OXSecurity reproduced the issue with a 2 MB archive that forced node-tar 7.5.18 to decompress the full 2GiB.
Key questions
Q: What breaks when archive decompression has no output limits?
A: Without output limits, a small compressed archive can expand into gigabytes of data, which exhausts CPU and disk before the application can recover.
Q: Why do decompression bombs create denial-of-service risk even without authentication?
A: They exploit trust in file input rather than trust in user identity.
Q: How can security teams know whether archive abuse is being contained?
A: Teams should look for three signals: blocked attempts to write outside extraction paths, detonation results that show dropped executables or LNK files, and endpoint alerts for unusual autorun persistence.
Practitioner guidance
- Patch node-tar to the fixed release Move all deployments using node-tar to 7.5.19 or later, then verify that application bundles, transitive dependencies, and container images no longer pin vulnerable versions.
- Add decompression ratio limits Set explicit limits for compressed-to-decompressed expansion so archive parsing aborts before a tiny payload can create runaway output.
- Cap archive entry counts and output size Treat file-count ceilings and total extracted bytes as separate controls, because a bomb can trigger through many small entries as well as a single inflated stream.
Bottom line: A tiny crafted archive can exhaust CPU and disk when decompression is not bounded at the output layer.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:38 pm
Unbounded decompression is a control-design failure, not a parsing bug. The issue in node-tar is that the library treated archive expansion as an open-ended stream rather than a governed resource. That matters because DoS risk appears when the control boundary is the parser, not the application, and the parser has no notion of cumulative cost. Practitioners should treat output growth as a first-class security property, not a side effect of file handling.
A question worth separating out:
Q: What should teams do when a library vulnerability exposes archive-processing services?
A: They should patch the library, inventory every application and container that depends on it, and remove direct trust in user-controlled archives where possible. The goal is to shorten exposure and make the parser enforce explicit resource boundaries, because dependency patches alone do not fix unsafe ingestion design.
👉 Read our full editorial: Node-tar decompression DoS exposes the need for archive limits