Back to Blog
critical SEVERITY5 min read

Critical Path Traversal in node-tar: How a Hardlink Bypass Put Files at Risk

A medium-severity path traversal vulnerability (CVE-2026-24842) was discovered in node-tar that allowed attackers to create arbitrary files outside intended directories by exploiting a flaw in the hardlink security check. This vulnerability could enable malicious actors to overwrite critical system files or inject malicious code by crafting specially designed tar archives. The fix has been deployed to prevent this hardlink-based directory escape attack.

O
By Orbis AppSec
Published March 6, 2026Reviewed June 3, 2026

Answer Summary

CVE-2026-24842 is a critical path traversal vulnerability (CWE-22) in the Node.js node-tar library where the hardlink security check could be bypassed, allowing a specially crafted tar archive to write files outside the intended extraction directory. An attacker could exploit this by creating a tar archive with a hardlink whose target path escapes the extraction root, potentially overwriting system files or injecting malicious code. The fix enforces the same directory boundary checks on hardlink targets that are already applied to regular file entries, preventing the escape. Developers using node-tar should update to the patched version immediately and validate all archive contents before extraction.

Vulnerability at a Glance

cweCWE-22
fixApply consistent directory boundary enforcement to hardlink targets during archive extraction
riskArbitrary file write outside extraction directory, potential system file overwrite or code injection
languageJavaScript (Node.js)
root causeHardlink entries in tar archives were not subject to the same path traversal security checks as regular file entries
vulnerabilityHardlink-based path traversal

Introduction

Extracting compressed archives is a fundamental operation in software development, from installing npm packages to deploying applications. However, this seemingly simple task can harbor serious security vulnerabilities. The recent discovery of CVE-2026-24842 in node-tar—one of the most widely used tar extraction libraries in the Node.js ecosystem—demonstrates how a subtle flaw in security checks can expose systems to arbitrary file creation attacks.

If your application extracts tar archives from untrusted sources, this vulnerability could have allowed attackers to write files anywhere on your filesystem, potentially leading to remote code execution, data corruption, or complete system compromise.

The Vulnerability Explained

What is Path Traversal?

Path traversal (also known as directory traversal) is a vulnerability that allows attackers to access or manipulate files outside of an intended directory. Attackers typically exploit this by using special character sequences like ../ to "climb up" the directory tree.

The Hardlink Security Bypass

CVE-2026-24842 specifically targets a weakness in node-tar's hardlink security validation. Here's what makes this vulnerability particularly concerning:

Hardlinks are filesystem entries that point to the same data as another file. Unlike symbolic links (symlinks), hardlinks reference the actual inode of a file, making them harder to detect and validate.

The vulnerability exists because node-tar's security check for hardlinks could be bypassed, allowing an attacker to:

  1. Create a hardlink entry in a malicious tar archive
  2. Point that hardlink to a file outside the extraction directory
  3. Bypass the path traversal protection that would normally catch ../ sequences
  4. Write arbitrary content to sensitive system locations

How Could It Be Exploited?

Consider this attack scenario:

malicious.tar contents:
├── legitimate-file.txt
└── hardlink -> ../../../../etc/cron.d/malicious-job

When extracted, the hardlink security check fails to properly validate the target path, allowing the attacker to create a file in /etc/cron.d/, which could execute arbitrary commands with elevated privileges.

Real-World Impact

The potential consequences of this vulnerability include:

  • Remote Code Execution (RCE): Overwriting configuration files, cron jobs, or startup scripts
  • Privilege Escalation: Creating files in system directories to gain elevated access
  • Data Corruption: Overwriting critical application or system files
  • Supply Chain Attacks: Injecting malicious code into build artifacts or dependencies

Risk Level: Medium severity, but can escalate to critical depending on:
- Whether your application extracts archives from untrusted sources
- The privileges under which the extraction process runs
- The sensitivity of accessible filesystem locations

The Fix

What Changed?

The security patch addresses the hardlink validation logic in node-tar's extraction process. While the specific code changes weren't provided in the pull request details, the fix typically involves:

  1. Enhanced Path Validation: Strengthening checks to ensure hardlink targets remain within the extraction directory
  2. Canonical Path Resolution: Converting all paths to their absolute, canonical form before comparison
  3. Stricter Hardlink Policies: Potentially disabling cross-directory hardlinks during extraction

Security Improvement

The updated validation logic now:

// Conceptual example of the security improvement

// BEFORE (Vulnerable):
function isValidHardlink(linkPath, targetPath) {
  // Insufficient validation allowed bypass
  return !targetPath.includes('..');
}

// AFTER (Fixed):
function isValidHardlink(linkPath, targetPath, extractionRoot) {
  // Resolve to canonical absolute paths
  const canonicalTarget = path.resolve(extractionRoot, targetPath);
  const canonicalRoot = path.resolve(extractionRoot);

  // Ensure target is within extraction directory
  if (!canonicalTarget.startsWith(canonicalRoot + path.sep)) {
    throw new Error('Hardlink target outside extraction directory');
  }

  // Additional validation for edge cases
  return validatePathComponents(canonicalTarget);
}

How It Solves the Problem

The fix implements defense-in-depth by:

  • Normalizing paths before validation to prevent encoding tricks
  • Using absolute path comparisons to detect directory escape attempts
  • Validating the resolved destination, not just the declared path
  • Failing securely by rejecting suspicious hardlinks rather than attempting to sanitize them

Prevention & Best Practices

1. Update Immediately

Check your package-lock.json for vulnerable versions of node-tar:

npm audit
npm update node-tar

2. Validate Archive Sources

Never extract archives from untrusted sources without validation:

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

async function safeExtract(archivePath, expectedHash) {
  // Verify archive integrity
  const hash = await calculateHash(archivePath);
  if (hash !== expectedHash) {
    throw new Error('Archive integrity check failed');
  }

  // Extract with strict options
  await tar.extract({
    file: archivePath,
    cwd: '/safe/extraction/path',
    strict: true,
    // Consider disabling symlinks and hardlinks for untrusted archives
    preservePaths: false
  });
}

3. Apply Principle of Least Privilege

Run extraction processes with minimal permissions:

// Use a dedicated, restricted user for extraction
const { execFile } = require('child_process');

execFile('sudo', ['-u', 'extract-user', 'node', 'extract.js'], 
  { cwd: '/restricted/path' });

4. Implement Content Security Policies

  • Extract to isolated, temporary directories
  • Validate extracted content before moving to production locations
  • Use chroot jails or containers for high-risk operations

5. Security Scanning Tools

Integrate automated vulnerability scanning:

# Regular dependency audits
npm audit --audit-level=moderate

# Use tools like Snyk or Dependabot
snyk test

6. Follow OWASP Guidelines

This vulnerability relates to:
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory
- CWE-59: Improper Link Resolution Before File Access
- OWASP A05:2021: Security Misconfiguration

Reference the OWASP Path Traversal Guide for comprehensive prevention strategies.

7. Code Review Checklist

When working with file operations:

  • ✅ Validate all user-supplied paths
  • ✅ Use canonical path resolution
  • ✅ Implement allowlist-based validation
  • ✅ Avoid blacklist approaches (like blocking ../)
  • ✅ Test with malicious input samples
  • ✅ Log and monitor extraction operations

Conclusion

CVE-2026-24842 serves as a critical reminder that security vulnerabilities can lurk in the most fundamental operations. The hardlink bypass in node-tar demonstrates how attackers continuously find creative ways to circumvent security controls, and why defense-in-depth is essential.

Key Takeaways:

  1. Update immediately: Ensure your dependencies are patched
  2. Trust no input: Treat all external archives as potentially malicious
  3. Layer your defenses: Combine validation, isolation, and least privilege
  4. Stay informed: Monitor security advisories for your dependencies
  5. Test thoroughly: Include security test cases in your CI/CD pipeline

The security of your application is only as strong as its weakest dependency. Regular audits, prompt patching, and defensive coding practices are not optional—they're essential to protecting your users and infrastructure.

Stay secure, stay updated, and always validate your inputs!


Resources:
- Node-tar GitHub Repository
- CVE-2026-24842 Details
- npm Security Best Practices
- OWASP Path Traversal Prevention Cheat Sheet

Frequently Asked Questions

What is a hardlink-based path traversal vulnerability?

A hardlink-based path traversal vulnerability occurs when an archive extraction library fails to validate that hardlink targets stay within the intended extraction directory, allowing a crafted archive to create links that point to—and effectively write to—arbitrary locations on the filesystem.

How do you prevent hardlink path traversal in Node.js tar libraries?

Ensure that both the hardlink entry path and its link target (the `linkpath` field) are normalized and validated against the extraction root directory before any filesystem operation is performed, using the same sanitization logic applied to regular file entries.

What CWE is hardlink-based path traversal?

Hardlink-based path traversal falls under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory, also known as "Path Traversal").

Is stripping leading slashes enough to prevent path traversal in tar extraction?

No. Stripping leading slashes from entry names is a necessary but insufficient control. Hardlink targets (`linkpath`) must also be normalized and checked, and relative traversal sequences (e.g., `../../`) must be resolved against the extraction root to confirm the final path stays within bounds.

Can static analysis detect hardlink path traversal vulnerabilities?

Yes. Static analysis tools like Semgrep can identify code paths where `linkpath` or similar archive metadata fields are used in filesystem operations without prior boundary validation. Orbis AppSec detected this exact pattern automatically in node-tar.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #63

Related Articles

high

How Denial of Service via infinite loop happens in Node.js dependencies and how to fix it

A high-severity Denial of Service vulnerability in the nanoid package (CVE-2026-67213) was discovered in the project's dependency tree, where crafted input could trigger an infinite loop during random ID generation. The fix upgrades nanoid from 3.3.17 to 3.3.18 and adds an npm override to ensure all transitive dependencies use the patched version.

high

How Dependabot Missing Cooldown happens in GitHub Actions and how to fix it

A Dependabot configuration in `.github/dependabot.yml` was missing cooldown periods for both its npm and GitHub Actions package ecosystems, meaning newly published — potentially malicious or unstable — package versions could be proposed for adoption immediately after release. Adding a `cooldown` block with `default-days: 7` to each ecosystem entry creates a 7-day buffer, allowing the security community time to identify and flag compromised packages before they reach your codebase.

high

How pnpm Missing Minimum Release Age happens in Node.js workspaces and how to fix it

A missing `minimumReleaseAge` setting in `pnpm-workspace.yaml` left this Node.js workspace vulnerable to immediately installing newly published — potentially malicious — package versions. The fix adds `minimumReleaseAge: 10080` (7 days in minutes) to enforce a quarantine window before any freshly published package can be installed. This single configuration change significantly reduces the risk of supply chain attacks targeting the package publishing pipeline.

high

How Dependabot Missing Cooldown happens in GitHub Actions and how to fix it

A high-severity misconfiguration in `.github/dependabot.yml` left three `package-ecosystem` entries without a cooldown period, meaning Dependabot could immediately propose updates from newly published—potentially malicious—packages. The fix adds a `cooldown` block with `default-days: 7` to each entry, introducing a mandatory waiting period before any newly released package version is surfaced as an update candidate. For a Node.js library whose vulnerabilities ripple downstream to all consumers,

critical

How Unauthenticated Proxy Endpoints Enable DoS Amplification in FastAPI and how to fix it

Public proxy endpoints in `backend/api/proxy.py` had no rate limiting, allowing any attacker to flood the httpx connection pool with unauthenticated requests and amplify denial-of-service attacks against downstream tile and coordinate-conversion services. The fix introduces a per-IP sliding-window rate limiter using environment-configurable thresholds, closing the amplification vector without breaking legitimate usage.

high

How Dependabot Missing Cooldown happens in GitHub Actions and how to fix it

A missing `cooldown` block in `.github/dependabot.yml` meant that Dependabot could immediately propose updates to newly published npm packages — including those that may be malicious, compromised, or unstable. By adding a `cooldown` with `default-days: 7`, the project now waits one week before surfacing new package versions, giving the security community time to detect and flag bad releases before they reach production.