Node-tar decompression bombs: are your archive controls keeping up?

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.

NHIMG editorial — based on content published by OXSecurity: node-tar decompression DoS vulnerability analysis

By the numbers:

• A tiny 2 MB archive forced node-tar 7.5.18 to decompress the full 2 GiB, while 7.5.19 aborted much earlier.
• The vulnerability affects all versions up to 7.5.18 and was patched in 7.5.19.

Questions worth separating out

Q: What breaks when a service processes untrusted archives without decompression limits?

A: A small compressed file can expand into far more data than the service can safely handle, which exhausts CPU, fills disk, and can crash the application or host.

Q: Why do archive parsers create availability risk in privileged automation flows?

A: Because the parser often runs under a service account or pipeline identity that can write to shared storage and trigger downstream jobs.

Q: What do security teams get wrong about per-chunk size checks?

A: They assume a maximum read size prevents abuse, but an attacker can still force a stream to decompress far more than any single chunk limit suggests.

Practitioner guidance

• Patch node-tar to the fixed release Move all direct and transitive consumers of node-tar to 7.5.19 or above, then verify lockfiles and container images so older copies are not still being loaded by build jobs or runtime services.
• Enforce cumulative decompression limits Configure a hard cap on total decompressed bytes and decompression ratio before archive extraction is allowed to continue.
• Isolate archive processing identities Run archive extraction in low-privilege service accounts with tight storage quotas and no broad filesystem write access, so a decompression bomb cannot consume shared infrastructure or reach sensitive paths.

What's in the full analysis

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• The exact reproduction path using a crafted gzip’d tar archive and the local test case that expands a 2 MB payload into 2 GiB.
• The patch logic in node-tar 7.5.19, including how compressed and decompressed byte counters enforce the ratio limit.
• The specific code-path discussion in src/parse.ts that shows where the decompression check is applied before allocation.
• The affected-version and remediation summary that teams can use to validate their dependency inventories and upgrade plans.

👉 Read OXSecurity's analysis of the node-tar decompression DoS vulnerability →

Node-tar decompression bombs: are your archive controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →