How Denial of Service via Gzip Bomb happens in Node.js and how to fix it

The Backup System That Could Be Brought to Its Knees

The @xen-orchestra/backups package is responsible for a high-stakes job: managing VM backups in the Xen Orchestra virtualization platform. Backup workflows routinely read, write, and extract archive files — which makes the tar extraction library a critical trust boundary. When that library has an unbounded decompression vulnerability, a single malicious archive is enough to take the entire backup service offline.

That is exactly the scenario described by CVE-2026-59873: a crafted gzip bomb fed to node-tar versions before 7.5.19 can exhaust server resources and cause a Denial of Service. Trivy's static analysis scanner flagged the vulnerable version locked in yarn.lock, and an automated fix upgraded the dependency before the issue could be exploited in production.

The Vulnerability Explained

What Is a Gzip Bomb?

A gzip bomb (also called a "decompression bomb") is a compressed file engineered to have an extreme compression ratio — sometimes millions-to-one. The file on disk might be only a few kilobytes, but when a decompressor naively processes it, the output balloons to gigabytes or terabytes of data. If the decompressor holds that output in memory, or even just tries to write it to disk, the host system runs out of resources.

Where the Problem Lives in node-tar

The vulnerable code path is inside node-tar's gzip decompression layer. When tar encounters a .tar.gz archive, it pipes the raw bytes through Node.js's built-in zlib gunzip stream. In versions prior to 7.5.19, there was no upper bound enforced on how much decompressed data could be produced before the library signaled an error or halted processing.

The yarn.lock entry before the fix pinned the resolved version at 7.5.16:

tar@^7.5.3:
  version "7.5.16"
  resolved "https://registry.yarnpkg.com/tar/-/tar-7.5.16.tgz#f11e063afed4554f758049d082909e37d6b53ced"
  integrity sha512-56adEpPMouktRlBLXiaYFFzZ/3+JXa8P9n7WbR+ibIjtviN55mEaOkiysCnPnWm+7kkui1Dn8J9l+g6zV8731w==

Version 7.5.16 sits below the patched threshold of 7.5.19, meaning the decompression safeguards introduced in the patch were absent.

A Concrete Attack Scenario

Consider the backup restore workflow in @xen-orchestra/backups. An operator (or an automated process with access to the backup store) triggers a restore operation by pointing the system at a .tar.gz archive. The tar library begins extracting the archive:

1. The attacker crafts a .tar.gz file that is, say, 50 KB compressed but expands to 50 GB of zero bytes — a classic gzip bomb structure using nested or highly repetitive compressed streams.
2. The backup service calls into node-tar to extract the archive, passing the file path or stream as input.
3. node-tar 7.5.16 begins decompressing the gzip stream with no size check. Node.js's event loop is blocked or slowed; memory consumption skyrockets.
4. The host's available RAM is exhausted. The Node.js process is killed by the OOM killer, or the system becomes unresponsive.
5. All backup and restore operations are unavailable until the service is manually restarted.

Because the backup store could be written to by any system or user with storage access — including compromised VMs — the attack surface is realistic and the impact is severe.

The Fix

What Changed

The fix touches two files:

@xen-orchestra/backups/package.json — The version range for tar was tightened from ^7.5.3 to ^7.5.19:

-    "tar": "^7.5.3",
+    "tar": "^7.5.19",

This ensures that npm/yarn will never resolve a version of tar below 7.5.19 for this package, even if the lockfile is deleted and regenerated.

yarn.lock — The resolved version and integrity hash were updated from 7.5.16 to 7.5.22:

-tar@^7.5.3:
-  version "7.5.16"
-  resolved "https://registry.yarnpkg.com/tar/-/tar-7.5.16.tgz#f11e063afed4554f758049d082909e37d6b53ced"
-  integrity sha512-56adEpPMouktRlBLXiaYFFzZ/3+JXa8P9n7WbR+ibIjtviN55mEaOkiysCnPnWm+7kkui1Dn8J9l+g6zV8731w==
+tar@^7.5.19:
+  version "7.5.22"
+  resolved "https://registry.yarnpkg.com/tar/-/tar-7.5.22.tgz#a696f998136e71487dc3f869a85bba2c67971ba9"
+  integrity sha512-MFO/QzvtAOmJbkhOaCTvbGcFN9L9b+JunIsDwaKljSOdcLMea3NJ1k9Usz/rjdfSXTq4dfzfeS7W4p4YOAAHeA==

Updating the lockfile is critical: without it, a yarn install --frozen-lockfile in CI would continue installing 7.5.16 regardless of the package.json change.

Why This Fix Works

node-tar 7.5.19 introduced internal decompression size limits in the gzip processing pipeline. When the uncompressed output of a gzip stream exceeds the configured threshold, the library throws an error and halts extraction rather than continuing to consume memory. This transforms a silent resource-exhaustion condition into a catchable error that the calling application can handle gracefully — logging the event, alerting operators, and discarding the malicious archive.

The fix is a defense-in-depth measure at the library level: it does not require any changes to the application code in @xen-orchestra/backups itself, because the protection is baked into the patched version of tar.

Prevention & Best Practices

1. Pin Minimum Safe Versions, Not Just Major Ranges

Using ^7.5.3 was too permissive — it allowed any 7.x.y version where y ≥ 3, which included the vulnerable 7.5.16. When a CVE specifies a minimum safe version, update the lower bound of your range explicitly (e.g., ^7.5.19).

2. Audit Lockfiles as Part of Your Security Posture

yarn.lock and package-lock.json are the ground truth of what actually gets installed. A scanner that only reads package.json may miss transitive or resolved-version mismatches. Tools like Trivy, Snyk, and npm audit can scan lockfiles directly.

3. Apply OS-Level Resource Controls

Even with a patched library, applying resource limits to Node.js processes that handle untrusted archives adds a second layer of defense:

# Example: limit memory for a Node.js process via systemd
MemoryMax=2G

Or in a container environment:

resources:
  limits:
    memory: "2Gi"

4. Validate Archive Sources

Where possible, only extract archives from trusted, authenticated sources. For backup workflows, verify the integrity of archives with a cryptographic signature or hash before passing them to tar.

5. Follow CWE-400 Mitigations

CWE-400: Uncontrolled Resource Consumption recommends:
- Implementing timeouts on resource-intensive operations
- Setting explicit limits on input sizes before processing
- Using libraries that enforce such limits internally (as this fix does)

Key Takeaways

• node-tar versions below 7.5.19 have no decompression size limit — any application that extracts user-influenced .tar.gz files with these versions is vulnerable to resource exhaustion.
• The yarn.lock resolved version (7.5.16) was the actual installed version, not the package.json range — lockfile scanning is essential to catch this class of vulnerability.
• Backup and restore workflows are high-value DoS targets because an outage directly impacts data recovery capabilities; library security in these paths deserves extra scrutiny.
• Upgrading tar to 7.5.22 (via ^7.5.19) requires both package.json and yarn.lock changes — updating only one file leaves the other out of sync.
• A 50 KB gzip bomb can take down a Node.js service with gigabytes of RAM — compressed archive processing must always be treated as a resource-consumption risk.

How Orbis AppSec Detected This

• Source: Archive files processed during VM backup/restore operations in @xen-orchestra/backups, where the origin of .tar.gz content may be attacker-influenced.
• Sink: The node-tar gzip decompression pipeline, called whenever tar extracts a compressed archive — no decompression size limit was enforced in version 7.5.16.
• Missing control: No upper bound on decompressed output size in the gzip stream handler; no pre-extraction size validation in the calling code.
• CWE: CWE-400: Uncontrolled Resource Consumption
• Fix: The tar dependency in @xen-orchestra/backups/package.json was updated from ^7.5.3 to ^7.5.19, and yarn.lock was regenerated to resolve version 7.5.22, which includes internal decompression limits.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-59873 is a reminder that even well-established, widely-used Node.js libraries can harbor critical vulnerabilities — and that patch-level version differences matter enormously. The gap between tar 7.5.16 and 7.5.19 is the difference between a service that can be taken offline with a 50 KB file and one that safely rejects the attack. For systems like @xen-orchestra/backups, where archive extraction is a core function and availability is paramount, keeping dependencies current and scanning lockfiles for known CVEs is not optional hygiene — it is a fundamental security control.

References

• CWE-400: Uncontrolled Resource Consumption
• OWASP Denial of Service Cheat Sheet
• node-tar on npm
• Semgrep rules for dependency vulnerabilities
• fix: upgrade tar to 7.5.19 (CVE-2026-59873)