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

medium

How insecure update manifest parsing happens in C++ UpdateHelper.cpp and how to fix it

TrafficMonitor's software update mechanism in `UpdateHelper.cpp` fetched and parsed update manifests from remote servers without validating the version string or enforcing trusted download URLs, leaving users exposed to man-in-the-middle (MITM) attacks. An attacker on the same network could intercept the update channel and inject a malicious binary under a crafted version string or an HTTP download link pointing to attacker-controlled infrastructure. The fix adds strict version-string sanitizati

high

How integer overflow in malloc happens in C bipartite matching and how to fix it

A high-severity integer overflow vulnerability was discovered in the bipartite matching algorithm implementation where unchecked multiplication operations for memory allocation could wrap around, causing undersized buffer allocations and subsequent heap overflow. The fix replaces vulnerable `malloc(sizeof(int) * V)` patterns with safe `calloc(V, sizeof(int))` calls and adds proper bounds validation to prevent exploitation.

high

How integer truncation heap overflow happens in C++ UEFI ACPI parsing and how to fix it

A high-severity integer truncation vulnerability was discovered in `Mobility.Uefi.Acpi.cpp` where heap allocation sizes were stored in a 16-bit integer (`MO_UINT16`), causing silent truncation when the computed size exceeded 65535 bytes. This led to undersized heap allocations followed by out-of-bounds writes, exploitable by an attacker who can influence ACPI SRAT table contents in virtualized environments. The fix promotes the size variable to `MO_UINTN` (platform-native width) to prevent trunc

critical

How API key exposure in configuration files happens in TOML config and how to fix it

A critical security vulnerability in `commands/webperf.toml` allowed API keys to be hardcoded directly in configuration files, creating a credential exposure risk. The documentation on line 11 suggested developers could provide `CRUX_API_KEY` or `GOOGLE_API_KEY` directly in the config, which could lead to these sensitive credentials being committed to version control or exposed in logs. The fix updated the documentation to explicitly require environment variables and warn against hardcoding cred

high

How path traversal happens in Ruby YARD server and how to fix it

A high-severity path traversal vulnerability (CVE-2026-41493) in YARD versions prior to 0.9.42 allowed attackers to read arbitrary files from servers running `yard server`. This fix upgrades the yard gem from 0.9.26 to 0.9.42 in the Gemfile and Gemfile.lock, closing a dangerous information disclosure vector that could expose configuration files, credentials, and source code.

high

How buffer overflow via sprintf() happens in C networking code and how to fix it

A high-severity buffer overflow vulnerability was discovered in `profile.c` where `sprintf()` was used to format server addresses without any bounds checking. An attacker who could influence the `SERVER_BASE_PORT` value or trigger integer overflow in the port calculation could write beyond the `server_address` buffer. The fix replaces `sprintf()` with `snprintf()` using explicit buffer size limits at both call sites (lines 99 and 220).