A new CVE dropped in node-tar, allowing a crafted gzip’d tar files to fill servers storage and crash services where user controlled tar files are processed by node-tar
Overview
A decompression vulnerability was found in node-tar, allowing a single crafted ZIP Bomb gzipped tar file to crash services using node-tar.
The issue affects all versions up to 7.5.18 and was patched in 7.5.19.
node-tar (<=7.5.18) decompresses gzip’d tar streams with no cap on output size or ratio, so a tiny gzip bomb expands unbounded (CPU/disk DoS).
The OX Research team was able to reproduce the issue locally with a 2 MB archive forces 7.5.18 to decompress the full 2GiB, while 7.5.19 aborts much earlier.
Affected Versions
| Affected Product(s) | Version(s) | Patched Version |
| node-tar | <= 7.5.18 | 7.5.19 |
Vulnerability Details
CVE: CVE-2026-59873
Description: A Decompression/parse DoS via unlimited input vulnerability in node-tar allows an attacker to exhaust server resources (disk space and CPU). Because the library does not enforce hard upper bounds on total decompressed data or entry counts, a small, maliciously crafted “Gzip Bomb” can be used to fill a server’s storage and crash services.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
CVSS Source: GHSA
CVSS Base score: 9.2
CVSS Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
Timeline
- Initially reported by Joshua van Rijswijk (Jvr2022)
- Patc
- GHSA published Jun 27, 2026
Impact Breakdown
- High Amplification Ratio: A tiny ~2 MB payload explodes into gigabytes of unpacked data, creating huge operational damage at almost zero bandwidth cost to the attacker.
- Resource Exhaustion: Decompression locks CPU usage at 100% while extraction consumes all available disk space, bringing the host system and neighboring services to a halt.
- Zero-Click Vulnerability: Requires no authentication or victim interaction—it triggers automatically whenever an application parses an untrusted archive.
Recommended Actions
- If you are directly exposing node-tar to user input, or have an automated service that uses it to decompress tar files from external sources, patch immediately to 7.5.19 or above
Technical Analysis
Root Cause
The tar parser feeds the compressed input through a gunzip stream and forwards every decompressed chunk to the tar block consumer.
In <= 7.5.18 there is no accounting of how much data comes out of the decompressor relative to how much went in.
The `maxReadSize` option only bounds the size of individual read chunks (default 16 MB) – it does not cap cumulative output – so a stream of highly compressible data (e.g. zeros) is expanded indefinitely.
The Fix
The parser now tracks compressed bytes read (`COMPRESSEDBYTESREAD`) and decompressed bytes read (`DECOMPRESSEDBYTESREAD`), and on every decompressed chunk checks the running ratio. Once it exceeds `maxDecompressionRatio` (default 1000), the stream is aborted before the bomb finishes expanding.
By analyzing the patch, we can see the code added a check for max decompression ratio, to prevent from decompressing files crossing that max size boundary.
From src/parse.ts
Additionally, the decompression data size ratio is being validated before the data is being allocated.
From src/parse.ts
