Notifications
Clear all
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.
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
02/08/2026 12:38 pm
Archive inflation is a governance problem, not just a parsing bug. When a library accepts untrusted compressed input without cumulative limits, availability becomes dependent on assumptions that are usually undocumented. That is especially relevant in automated pipelines where service accounts and workloads inherit privileges from the surrounding platform. Practitioners should treat decompression limits as part of workload governance, not just application hardening.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Which accountability model should cover archive handling failures?
A: Ownership should sit with the application or platform team that enables the archive workflow, not only with the library maintainer. Security, engineering, and operations should agree who patches the parser, who sets resource ceilings, and who is responsible for the service identity that runs extraction.
👉 Read our full editorial: Node-tar decompression DoS exposes the need for archive limits
