Topic starter
02/08/2026 9:46 am
TL;DR: A tiny crafted gzip’d tar archive can expand into gigabytes of output in node-tar, exhausting CPU and disk space on services that process untrusted archives, according to OXSecurity. Archive handling needs explicit output caps and trust boundaries so decompression cannot consume resources unchecked.
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: 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.
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.
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.
Glossary terms: Decompression Bomb, Resource Exhaustion DoS, Trust Boundary, Decompression Ratio
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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