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.
At a glance
What this is: A node-tar vulnerability allows a crafted gzip’d tar archive to expand without output limits and crash services through CPU and disk exhaustion.
Why it matters: It matters to security and identity practitioners because any service that processes untrusted files needs explicit resource bounds around parsing, automation, and supply-chain dependencies.
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.
Context
Node-tar is a common archive-processing library, so a decompression denial of service matters wherever applications accept user-controlled or externally sourced tar files. The problem is not authentication bypass or code execution. It is an unbounded resource-consumption flaw that turns normal parsing into a host-level availability event when output growth is not explicitly constrained.
For identity and platform teams, the governance issue is trust boundary management around file ingestion. Any service account, workload, or automation flow that can unpack untrusted archives inherits the same exposure if decompression limits, file-count ceilings, and exception handling are missing. That makes this a control-design problem as much as a library patch issue.
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. The practical failure is not corruption but host-level denial of service. Any automated service that parses untrusted archives should assume decompression itself is a resource attack surface, not a harmless preprocessing step.
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. If a service automatically parses an uploaded or fetched archive, the attack begins as soon as the decompressor reads the file. No login is needed because the danger sits in the processing path, not in access to the application UI.
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. If those signals are absent, the environment may be accepting archive-based delivery without seeing the handoff to execution.
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.
Technical breakdown
How unlimited decompression becomes a denial of service
node-tar processes gzip’d tar streams by decompressing input and forwarding the output to the tar consumer. In vulnerable versions, the library did not enforce a hard cap on cumulative decompressed bytes or on the decompression ratio, so a highly compressible archive could expand far beyond its original size. The result is not subtle corruption but resource exhaustion: CPU stays busy expanding data while disk fills with output, and the host can no longer support normal work. A per-read limit alone is insufficient because a stream can still accumulate unbounded output across many chunks.
Practical implication: enforce cumulative decompression limits, not just per-read size checks.
Why max read size did not solve the problem
The article notes that maxReadSize only bounds individual chunks, not the total amount of data produced by the decompressor. That distinction matters because archive bombs exploit volume over time, not a single oversized read. A parser can remain technically within per-chunk limits while still generating gigabytes of output from a tiny input. The fix in 7.5.19 introduced tracking of compressed and decompressed bytes together, then aborted the stream once the configured ratio was exceeded. That is a classic example of control placement at the wrong layer if only input-size checks are used.
Practical implication: validate both input size and output growth at the parser boundary.
What the patch changed in the control model
The patched version introduces explicit accounting for compressed bytes read and decompressed bytes read, then compares the running ratio against maxDecompressionRatio. That changes the control model from passive parsing to active guardrails. Instead of assuming benign archives, the library now treats output amplification as a bounded-risk condition that can be stopped before full expansion completes. This is especially relevant for applications that process files automatically, because the attack triggers without user interaction once an untrusted archive reaches the parser.
Practical implication: add ratio-based abort logic wherever archive parsing is automated.
Threat narrative
Attacker objective: The attacker wants to exhaust host resources with a tiny archive so the target service becomes unavailable.
- Entry occurs when an application accepts a crafted gzip’d tar archive from an untrusted source and passes it to node-tar for decompression.
- Credential or authentication is not required because the archive triggers parsing automatically, so the attacker relies on input trust rather than account access.
- Escalation happens as the archive expands into gigabytes of output, consuming CPU and disk until the host and nearby services fail.
- Impact is a denial of service that crashes the affected service and can destabilise the broader environment.
Breaches seen in the wild
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Archive limits belong at the trust boundary where files enter automation. The article shows why per-chunk size checks are not enough for services that ingest external archives. If the control only sees one read at a time, a small bomb can still turn into a large operational outage. The governance lesson is to define explicit decompression ratio, entry-count, and output-size thresholds wherever automation touches untrusted content.
Decompression bombs are a broader supply-chain and workload-identity concern. A vulnerable library embedded in an automated service can expose every workload or service account that depends on it, even when the identity layer is correctly configured. This is where identity governance intersects application security: the privilege of the process matters less than the resource boundary it can reach. Teams should map archive-processing dependencies to the services and workloads that consume them.
Cumulative accounting is the named concept this case makes unavoidable. The practical failure mode is not simply “no patch applied” but “no enforced relationship between compressed input and decompressed output.” That failure mode is easy to miss in reviews because the parser appears to be doing ordinary work right up until it saturates the host. Practitioners should make ratio-based resource accounting a standard control for any untrusted file pipeline.
What this signals
Cumulative output accounting is the control gap this incident exposes. Parsing limits that measure only the size of a single read do not protect services from archive bombs because the attacker wins through repetition and amplification. For practitioners, the question is whether any ingestion path can still expand untrusted content without a hard abort condition.
Services that unpack user-controlled archives should be treated as availability-sensitive workloads, not just application features. That means resource ceilings, failure-closed parsing, and dependency hygiene need to be part of the operating model for both platform teams and the owners of the workload or service account that performs extraction.
For practitioners
- 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.
- Restrict archive handling to trusted ingestion paths Separate user-controlled upload flows from internal automation and avoid giving general-purpose services direct access to arbitrary external archives.
- Monitor for parse-time resource spikes Alert on sustained CPU saturation, rapid disk growth, and repeated extraction failures in services that unpack third-party or user-supplied tar files.
Key takeaways
- A tiny crafted archive can exhaust CPU and disk when decompression is not bounded at the output layer.
- The article's reproduced 2 MB to 2 GiB expansion shows how little attacker bandwidth is needed to create major service disruption.
- Explicit decompression ratios and cumulative output limits are the control that turns archive parsing from an open-ended risk into a governed one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Resource spikes and failed extractions need visibility, and CIS logging controls support detection. |
| Recommendation — Instrument archive-processing services so CPU, disk, and extraction failures are observable and alertable. | ||
| NIST CSF 2.0 | PR.PS-04 — Configuration management | The fix depends on secure parser configuration and explicit limits at the service boundary. |
| Recommendation — Set decompression and extraction limits as enforced configuration, not optional application defaults. | ||
| MITRE ATT&CK | TA0040 — Impact | The attack objective is service disruption through resource exhaustion, which maps directly to impact. |
| Recommendation — Classify archive-bomb behaviour as an impact technique and hunt for sustained resource saturation during parsing. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | The vulnerability is a classic availability attack against a service that lacks output throttling. |
| Recommendation — Apply SC-5 to bound decompression output and prevent resource exhaustion in archive handlers. | ||
Key terms
- Decompression Bomb: A file that is small on disk but expands dramatically when unpacked, often consuming extreme CPU, memory, or storage during processing. Attackers use it to overload systems that trust the archive size. The danger is especially acute in shared services that process untrusted input without strict resource limits.
- Resource Exhaustion DoS: A denial-of-service condition caused when a workload consumes CPU, memory, or disk faster than the system can recover. In archive processing, the attack often relies on expansion or repeated allocation rather than malformed code execution, which makes limit enforcement the key defensive control.
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
- Decompression Ratio: Decompression ratio is the relationship between compressed input size and uncompressed output size. When that ratio is not enforced, small inputs can create huge outputs, so ratio tracking becomes a practical safety control for file parsers and automation that ingest untrusted archives.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the operational contexts security teams manage every day. It helps practitioners connect identity controls to the broader service and automation risks that shape modern security programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org