CVE-2026-24842

What it actually does

node-tar versions prior to 7.5.7 incorrectly validate hardlink entries in TAR archives using path resolution semantics that differ from the logic used when creating the hardlink. A malicious archive can pass the library's path traversal checks while causing extraction to create a hardlink that points outside the intended extraction directory. The main impact is unauthorized access to, or linking against, arbitrary files reachable by the extracting process. Because exploitation requires an application or user to extract an attacker-controlled archive, the vulnerability is not typically self-propagating, but it can cross security boundaries when archive extraction is performed in build systems, package ingestion services, CI/CD jobs, developer tooling, upload processors, or automated unpacking workflows.

Why it matters to the business

If a vulnerable application extracts untrusted TAR files, an attacker may be able to make the extraction process reference sensitive files outside the expected workspace. This can expose secrets, source code, configuration files, SSH keys, tokens, or other local files to later processing, packaging, upload, or logging steps. In automated build or artifact-processing environments, the flaw can undermine isolation assumptions and may lead to credential leakage, supply-chain compromise, or unauthorized modification of artifacts. The CVSS score is high, but EPSS is currently low and the issue is not listed in CISA KEV, so prioritization should focus first on internet-facing or automated systems that process untrusted archives.

How an attack unfolds

An attacker prepares a TAR archive containing hardlink entries with crafted path and link target values. The archive is designed so that node-tar's pre-extraction security validation evaluates the hardlink as safe, while the later hardlink creation logic resolves the same paths differently. When a vulnerable application extracts the archive, node-tar creates a hardlink that points outside the designated extraction directory. The attacker then relies on application behavior after extraction: for example, the application may read, package, publish, scan, transform, or return extracted files, inadvertently exposing the contents or metadata of files outside the intended directory. Exploitation requires that the target process extract an attacker-supplied TAR archive and that the process account has filesystem access to the targeted external file.

How to fix it

Upgrade node-tar to version 7.5.7 or later. For source-based consumers of isaacs/node-tar, ensure the fix commit 4a37eb9a1cf1137df4eb70c5c7f849f412ff3cdb or an equivalent release containing that change is present. Regenerate lockfiles after updating direct or transitive dependencies, and verify that all deployed artifacts use the fixed dependency version. Where immediate upgrade is not possible, avoid extracting untrusted TAR archives; reject archives containing hardlink entries; extract archives inside a temporary, isolated, least-privileged directory or container; prevent extraction processes from accessing sensitive host paths; and ensure post-extraction workflows do not follow or package hardlinks that escape the extraction root.

How to confirm the fix worked

Confirm the deployed dependency tree resolves node-tar to 7.5.7 or later, or to a build that includes commit 4a37eb9a1cf1137df4eb70c5c7f849f412ff3cdb. Use package manager inspection such as npm ls tar, yarn why tar, pnpm why tar, software composition analysis, SBOM review, or lockfile inspection to identify direct and transitive instances. Test representative archive-processing paths with benign TAR files containing hardlink entries and confirm that hardlinks resolving outside the extraction root are rejected or safely handled. Validate runtime controls by confirming extraction occurs in a restricted location with least-privileged filesystem access and that post-extraction processing does not include files outside the intended directory.

Typical attack path

1. Identify an application, service, build job, package ingestion flow, or developer tool that uses node-tar before version 7.5.7 to extract TAR archives.
2. Craft a malicious TAR archive containing hardlink entries whose validation path and creation path resolve differently.
3. Deliver the archive through an upload feature, dependency/package submission, artifact import, source bundle, CI/CD input, or other archive-processing workflow.
4. Trigger extraction by the vulnerable process.
5. Cause node-tar to create a hardlink pointing outside the intended extraction directory.
6. Abuse downstream processing of the extracted directory to read, copy, publish, log, or otherwise expose the linked external file.

How to detect it

Look for evidence that vulnerable systems extracted attacker-controlled TAR archives containing hardlink entries that target paths outside the intended extraction directory. Useful data sources include application upload logs, artifact ingestion logs, CI/CD job logs, package build logs, temporary extraction directories, file integrity monitoring, endpoint telemetry, EDR file creation events, and auditd or OS-level filesystem events for link creation. Investigate archives processed by vulnerable versions before upgrade, especially those received from untrusted users or external package sources. Forensic review should inspect TAR metadata for hardlink entries with absolute link targets, parent-directory traversal, unusual normalization behavior, or link targets referencing sensitive paths. On Linux, audit records for link or linkat syscalls by Node.js processes during archive extraction can help identify suspicious behavior. Also review downstream outputs, published artifacts, logs, or generated packages for unexpected inclusion of sensitive file contents or hardlinks referencing files outside extraction workspaces. There are no widely established public exploitation indicators or named threat actors associated with this issue in the provided data.

• TAR hardlink entry with typeflag 1
• linkname=../
• linkname=/
• ../ in TAR hardlink target
• absolute path in TAR hardlink target
• node process creating hardlinks during TAR extraction
• linkat syscall by node during archive extraction
• hardlink target outside extraction directory

What your security team should do

• Inventory applications, build systems, package-processing services, and developer tooling that extract TAR archives using node-tar.
• Prioritize upgrades for services that accept user-supplied archives, process third-party packages, or run in CI/CD and artifact-publishing pipelines.
• Upgrade node-tar to 7.5.7 or later and refresh lockfiles and deployed artifacts to remove vulnerable transitive copies.
• Add archive-validation controls that reject hardlinks, absolute paths, parent-directory traversal, and entries that resolve outside the extraction root.
• Run extraction workloads with least privilege in isolated temporary directories, containers, or sandboxes with no access to secrets or sensitive host paths.
• Review recent archive-processing activity for suspicious hardlink entries and unexpected files appearing in extracted workspaces.
• Add regression tests for malicious TAR hardlink and path traversal cases to prevent reintroduction of unsafe extraction behavior.