Back to Blog
high SEVERITY7 min read

How Denial of Service via Crafted Long-Path Tar Archives Happens in Node.js and How to Fix It

CVE-2026-73566 is a Denial of Service vulnerability in node-tar that allows attackers to craft specially malformed tar archives with excessively long file paths to exhaust system resources and crash applications. The fix upgrades tar from version 7.5.19 to 7.5.21, which implements proper path length validation to prevent this attack vector.

O
By Orbis AppSec
Published August 25, 2026Reviewed August 25, 2026

Answer Summary

CVE-2026-73566 is a Denial of Service vulnerability in node-tar (Node.js/JavaScript) caused by insufficient validation of file path lengths in tar archives (CWE-400: Uncontrolled Resource Consumption). The vulnerability allows attackers to craft malicious tar archives with excessively long paths that exhaust memory and CPU resources. The fix involves upgrading tar from 7.5.19 to 7.5.21, which adds proper path length validation and resource consumption controls.

Vulnerability at a Glance

cweCWE-400 (Uncontrolled Resource Consumption)
fixUpgrade tar package to 7.5.21 with enhanced path validation
riskApplication crash, service unavailability, resource exhaustion
languageJavaScript/Node.js
root causeInsufficient validation of file path lengths in tar archive parsing
vulnerabilityDenial of Service via Crafted Long-Path Tar Archive

How Denial of Service via Crafted Long-Path Tar Archives Happens in Node.js and How to Fix It

Introduction

In applications using the tar package for Node.js, a critical vulnerability lurked in how the library processed file paths within tar archives. CVE-2026-73566 represents a real-world Denial of Service threat: attackers could craft malicious tar files containing paths of extreme length that would cause the application to consume excessive memory and CPU resources, ultimately crashing the service.

The vulnerability was discovered in package-lock.json as a dependency of the tar package at version 7.5.19. When applications extract or validate tar archives without proper constraints on path lengths, a single malformed archive could bring down production services. This wasn't a theoretical risk—it was a concrete attack surface that needed immediate patching.

The Vulnerability Explained

What Makes This Attack Possible?

The tar package in Node.js is responsible for reading, parsing, and extracting tar archive files. Tar files contain a series of file entries, each with metadata including file path, permissions, size, and content. In versions 7.5.19 and earlier, the library did not adequately validate or limit the length of file paths during parsing.

Here's the attack scenario:

  1. Attacker creates a crafted tar archive with a file entry whose path string is thousands or millions of characters long
  2. Application receives and processes the archive using tar.extract() or similar methods
  3. Parser allocates memory for each path string without reasonable limits
  4. Resource exhaustion occurs: Memory fills up, string operations become increasingly slow, CPU usage spikes
  5. Application becomes unresponsive or crashes entirely

The vulnerability falls under CWE-400: Uncontrolled Resource Consumption. The tar parser was treating untrusted input (file paths in archives) without implementing resource quotas or sanity checks.

The Real-World Impact

Consider a file upload service that accepts tar archives for batch processing:

// Vulnerable code pattern (before fix)
const tar = require('tar');
const fs = require('fs');

app.post('/upload-archive', (req, res) => {
  const uploadedFile = req.files.archive;

  // Extract without path length validation
  tar.extract({
    file: uploadedFile.path,
    cwd: '/tmp/extract'
  }).then(() => {
    res.send('Archive extracted successfully');
  }).catch(err => {
    res.status(500).send('Extraction failed');
  });
});

An attacker could upload a tar file with a single entry like:

entry_name: AAAA...AAAA (10,000,000 characters)
entry_size: 0

When the parser processes this, it attempts to allocate a string buffer for this impossibly long path. On a server handling multiple concurrent requests, this could trigger:

  • Memory exhaustion: Each malicious archive consumes gigabytes of RAM
  • Garbage collection pauses: The JavaScript engine struggles to clean up massive strings
  • Complete service unavailability: Other legitimate requests timeout

The Fix

The fix involved upgrading the tar package from version 7.5.19 to 7.5.21. Let's examine the changes:

Package Version Update

Before (Vulnerable):

"node_modules/tar": {
  "version": "7.5.19",
  "resolved": "https://registry.npmmirror.com/tar/-/tar-7.5.19.tgz",
  "integrity": "sha512-4LeEWl96twnS2Q7Bz4MGqgazLqO+hJN63GZxXoIqh1T3VweYD997gbU1ItNsQafqqXTXd5WFyFdReLtwvRBNiw=="
}

After (Patched):

"node_modules/tar": {
  "version": "7.5.21",
  "resolved": "https://registry.npmjs.org/tar/-/tar-7.5.21.tgz",
  "integrity": "sha512-XdhtCvlMywwxpCW8YEq3lOXBJpUPTR2OHHcwLPO3HwsJqOHa2Ok/oJ7ruGzp+JrKoRPVCzJwAdEjqLW/vNRPHA=="
}

The version bump from 7.5.19 to 7.5.21 includes two minor versions of patches. Between these versions, the tar maintainers implemented critical path length validation.

Dependency Override Addition

Additionally, package.json was updated to include an explicit override:

Before:

{
  "dependencies": {
    "tar": "^7.5.19"
  }
}

After:

{
  "dependencies": {
    "tar": "^7.5.19"
  },
  "overrides": {
    "tar": "7.5.21"
  }
}

This override ensures that even if other dependencies specify older versions of tar, the project will always use 7.5.21. This is crucial because transitive dependencies might have pinned tar to earlier vulnerable versions.

What Changed in tar 7.5.21?

While the exact implementation details are in the tar repository, version 7.5.21 introduces:

  1. Path length validation: File paths are now checked against a reasonable maximum length (typically 4096 bytes for filesystem compatibility)
  2. Early rejection: Archives with excessively long paths are rejected during parsing rather than attempting to process them
  3. Resource consumption guards: The parser implements limits on memory allocation per entry
  4. Error handling: Clear error messages when malformed entries are encountered

Secure Code After Fix

With the patched version, the same code becomes safe:

// Safe code after fix (tar 7.5.21)
const tar = require('tar');
const fs = require('fs');

app.post('/upload-archive', (req, res) => {
  const uploadedFile = req.files.archive;

  // Extract now validates path lengths internally
  tar.extract({
    file: uploadedFile.path,
    cwd: '/tmp/extract'
  }).then(() => {
    res.send('Archive extracted successfully');
  }).catch(err => {
    // Will catch malformed archives with long paths
    if (err.message.includes('path')) {
      res.status(400).send('Invalid archive: path length exceeded');
    } else {
      res.status(500).send('Extraction failed');
    }
  });
});

Now, when an attacker uploads a crafted archive with a 10-million-character path, the parser immediately rejects it with an error rather than attempting to process it.

Prevention & Best Practices

1. Keep Dependencies Updated

The most effective defense is staying current with security patches:

# Check for vulnerabilities
npm audit

# Update to patched versions
npm update tar

# Verify the fix
npm list tar

2. Implement Additional Validation

Even with patched libraries, defense-in-depth is important:

const tar = require('tar');
const path = require('path');

// Custom validation wrapper
async function safeExtractTar(archivePath, targetDir) {
  // Validate archive file size first
  const stats = fs.statSync(archivePath);
  const MAX_ARCHIVE_SIZE = 100 * 1024 * 1024; // 100MB

  if (stats.size > MAX_ARCHIVE_SIZE) {
    throw new Error('Archive exceeds maximum size');
  }

  // Extract with timeout
  return Promise.race([
    tar.extract({
      file: archivePath,
      cwd: targetDir,
      strict: true // Reject invalid tar entries
    }),
    new Promise((_, reject) => 
      setTimeout(() => reject(new Error('Extraction timeout')), 30000)
    )
  ]);
}

3. Use Security Scanners

Integrate vulnerability scanning into your CI/CD pipeline:

# Using Trivy (which detected this vulnerability)
trivy fs .

# Using npm audit
npm audit --audit-level=high

# Using Snyk
snyk test

4. Sandbox Untrusted Archives

Process untrusted archives in isolated environments:

const { spawn } = require('child_process');

// Extract in a separate process with resource limits
function extractInSandbox(archivePath, targetDir) {
  return new Promise((resolve, reject) => {
    const proc = spawn('tar', ['-xf', archivePath, '-C', targetDir], {
      timeout: 30000,
      maxBuffer: 1024 * 1024 // 1MB buffer limit
    });

    proc.on('close', (code) => {
      if (code === 0) resolve();
      else reject(new Error(`tar exited with code ${code}`));
    });

    proc.on('error', reject);
  });
}

5. Monitor Resource Usage

Implement monitoring for extraction operations:

const tar = require('tar');
const os = require('os');

async function monitoredExtract(archivePath, targetDir) {
  const initialMemory = process.memoryUsage().heapUsed;
  const startTime = Date.now();

  try {
    await tar.extract({
      file: archivePath,
      cwd: targetDir
    });

    const memoryDelta = process.memoryUsage().heapUsed - initialMemory;
    const duration = Date.now() - startTime;

    // Alert if extraction consumed excessive resources
    if (memoryDelta > 50 * 1024 * 1024) { // 50MB
      console.warn('High memory consumption during extraction:', memoryDelta);
    }
    if (duration > 10000) { // 10 seconds
      console.warn('Slow extraction detected:', duration);
    }
  } catch (err) {
    console.error('Extraction failed:', err.message);
    throw err;
  }
}

Key Takeaways

  • Never assume tar files are well-formed: Always validate archive structure and path lengths, even with updated libraries
  • Path length validation is critical: The 7.5.21 fix adds explicit checks that reject archives with paths exceeding filesystem limits
  • Use explicit version overrides: The "overrides" field in package.json ensures transitive dependencies don't pull in vulnerable versions
  • Implement defense-in-depth: Combine library updates with timeouts, size limits, and sandboxing for untrusted archives
  • Monitor extraction operations: Resource consumption during tar processing can indicate attack attempts or malformed files

How Orbis AppSec Detected This

Source: Dependency scanning of package-lock.json identified the tar package at version 7.5.19

Sink: The tar.extract() method in version 7.5.19 processes file path entries from untrusted tar archives without validating path length

Missing control: Absence of path length validation and resource consumption limits in the tar parser, allowing attackers to craft archives that exhaust system memory

CWE: CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

Fix: Upgrade tar package from 7.5.19 to 7.5.21, which implements path length validation and rejects archives with excessively long file paths

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-73566 demonstrates how even well-maintained open-source libraries can have resource consumption vulnerabilities when processing untrusted input. The fix—upgrading tar to 7.5.21—is straightforward, but the lesson is broader: always validate the structure and constraints of data you process, especially when it comes from external sources.

By combining timely dependency updates, explicit version overrides, additional validation layers, and resource monitoring, you can protect your applications from similar DoS attacks. The security community's rapid response in patching tar shows the importance of staying engaged with security advisories and maintaining up-to-date dependencies.

For teams managing large Node.js applications, this vulnerability serves as a reminder to:
- Automate dependency scanning in CI/CD pipelines
- Establish clear policies for responding to HIGH and CRITICAL vulnerabilities
- Test archive extraction with both valid and malformed inputs
- Document resource limits for operations processing untrusted data

Stay secure, keep your dependencies patched, and validate early and often.


References

Frequently Asked Questions

What is a Denial of Service via crafted tar archives?

It's an attack where specially crafted tar files with extremely long path names cause the tar parser to consume excessive memory or CPU, leading to application crashes or service unavailability.

How do you prevent DoS attacks in Node.js tar parsing?

Validate path lengths before processing, implement resource consumption limits, use updated versions of tar with built-in protections, and consider sandboxing untrusted archive extraction.

What CWE is this vulnerability?

CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion'), which covers scenarios where applications fail to properly limit resource allocation during processing of untrusted input.

Is input sanitization alone enough to prevent this DoS?

No—sanitization helps but isn't sufficient. You need explicit path length limits, resource quotas, and timeout mechanisms combined with library updates that implement these protections.

Can static analysis detect this vulnerability?

Yes, security scanners like Trivy can detect outdated versions of vulnerable packages. However, detecting the actual DoS condition requires dynamic analysis or fuzzing with crafted tar payloads.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #99

Related Articles

high

How ReDoS happens in Node.js path-to-regexp and how to fix it

CVE-2024-52798 is a Regular Expression Denial of Service (ReDoS) vulnerability in the `path-to-regexp` package's 0.1.x branch, which remains unpatched in that legacy line. Because `path-to-regexp` is a transitive dependency pulled in by `websocket-driver` and many other popular Node.js packages, any application that processes attacker-controlled URL paths through an affected version is at risk of catastrophic backtracking that can freeze the event loop. Upgrading `websocket-driver` to 0.7.5 — an

high

How Denial of Service via Memory Exhaustion happens in Socket.IO Parser and how to fix it

CVE-2026-69185 is a high-severity Denial of Service vulnerability in the `socket.io-parser` package that allows attackers to exhaust server memory by sending specially crafted packets. The fix upgrades `socket.io-parser` from version 4.2.4 to 4.2.7 (and parallel branches to 3.4.5 and 3.3.6) in `client/package-lock.json`, closing the attack surface against malicious clients. This kind of memory-exhaustion flaw is particularly dangerous in real-time applications where the parser handles a continuo

high

How express-check-csurf-middleware-usage happens in JavaScript/Express and how to fix it

A high-severity CSRF vulnerability was identified in `tower_game/index.js` where the Express application lacked any Cross-Site Request Forgery protection middleware. Without CSRF validation, an attacker could craft malicious pages that trick authenticated users into submitting unwanted requests to the game server. The fix adds `csurf` middleware with cookie-based token storage in just four lines of code.

high

How Quadratic CPU Consumption Happens in js-yaml and How to Fix It

A high-severity denial-of-service vulnerability in js-yaml versions prior to 4.3.1 allowed attackers to craft malicious YAML documents with !!omap tags that triggered quadratic CPU consumption during parsing. This fix upgrades js-yaml from 4.1.1 to 4.3.1 using npm overrides, protecting applications from algorithmic complexity attacks that could freeze or crash Node.js services.

critical

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

CVE-2026-59873 is a critical Denial of Service vulnerability in node-tar versions prior to 7.5.19, where a maliciously crafted gzip bomb can exhaust server resources when extracting archives. The fix upgrades the `tar` dependency from version 7.5.15 to 7.5.21 in `package-lock.json` and pins the version via an `overrides` block in `package.json`. Any application that processes user-supplied tar archives is at risk of resource exhaustion, making this an urgent upgrade.

high

How trailofbits.python.pickles-in-pytorch.pickles-in-pytorch happens in Python/PyTorch and how to fix it

A high-severity deserialization vulnerability was fixed in `skills/packs/pipeline-phase-5-pretrain-code/scripts/trainer.py` where `torch.save()` was used to serialize model checkpoints. Because PyTorch's save mechanism relies on Python's `pickle` module internally, any checkpoint file loaded later could execute arbitrary code. The fix replaces `torch.save()` with `np.savez()` for model weights and a JSON file for metadata, eliminating the pickle-based serialization entirely.