CVE-2026-26960

What it actually does

node-tar versions 7.5.7 and earlier mishandle attacker-controlled tar archives when extracting with default options. A malicious archive can create a hardlink within the intended extraction directory whose link target resolves to a file outside that directory. Because subsequent archive entries or application logic may read from or write through that hardlink, the extraction boundary can be bypassed, giving the attacker an arbitrary file read/write primitive with the privileges of the process performing extraction. The issue requires a vulnerable application or workflow to extract an attacker-supplied archive; it does not provide remote code execution by itself, but file overwrite can become code execution if sensitive executable, configuration, startup, credential, or package files are modified.

Why it matters to the business

Systems that accept and unpack user-supplied tar files may allow an attacker to access or alter files that should be outside the upload or extraction area. Depending on what account performs extraction, this can lead to theft of secrets, tampering with application configuration, supply-chain compromise of build artifacts, corruption of user data, or follow-on code execution through overwritten scripts or dependencies. Although the vulnerability is not currently in CISA KEV and has a low EPSS score, public exploit availability increases urgency for applications, CI/CD systems, package-processing services, developer portals, artifact scanners, and any automation that extracts untrusted archives.

How an attack unfolds

An attacker first identifies a service, pipeline, CLI workflow, or backend job that uses node-tar 7.5.7 or earlier to extract tar archives using default options. The attacker then crafts a tar archive containing a hardlink entry whose apparent path is inside the extraction directory but whose link target points outside the extraction root. When the vulnerable extractor processes the archive, it creates the hardlink despite path protections intended to confine extraction. The attacker then includes additional archive content or relies on later application behavior to read from or write to the hardlink, causing operations in the extraction directory to affect the external target file. Practical outcomes depend on the extracting user's permissions: a low-privilege service account may expose application secrets or workspace files, while a privileged build or deployment process may allow modification of configuration, scripts, SSH material, dependency files, or other high-impact targets.

How to fix it

Upgrade node-tar to version 7.5.8 or later. For source-based consumers of isaacs/node-tar, ensure the fix commit 6b8eba0ef367ac937e703238daa6df94ae6f823f or a later equivalent is present. Rebuild and redeploy applications after dependency updates so the vulnerable package is removed from runtime images, serverless bundles, CI workers, containers, and developer tooling. If immediate upgrade is not possible, do not extract untrusted tar archives; isolate extraction in a disposable sandbox with a non-privileged user; extract into a newly created empty directory; reject archives containing hardlinks; validate every entry's final resolved path before and after extraction; and prevent extracted content from being processed as executable code. Treat archive extraction as unsafe input handling and apply filesystem allowlisting, least privilege, and cleanup after processing.

How to confirm the fix worked

Confirm dependency resolution no longer includes node-tar versions 7.5.7 or earlier. Check package manifests and lockfiles, then verify the effective installed package in built artifacts, containers, and deployment bundles. For npm-based projects, review package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, and node_modules/tar/package.json where applicable. Run software composition analysis after rebuilding to ensure the fixed version is present. Functionally validate by testing archive extraction with benign hardlink-containing tar files and confirming hardlinks to paths outside the extraction root are rejected or safely ignored. Also verify extraction runs as a low-privilege user and that uploaded archives cannot overwrite configuration, credentials, scripts, or dependency files outside the intended extraction directory.

Typical attack path

1. Find an application, automation workflow, or developer/build system that accepts tar archives from users or external sources.
2. Confirm or infer that the extraction path uses node-tar 7.5.7 or earlier with default extraction behavior.
3. Create a malicious tar archive containing a hardlink entry located inside the extraction directory but targeting a path outside the extraction root.
4. Submit or cause the vulnerable system to process the archive.
5. During extraction, the vulnerable library creates the hardlink and bypasses the intended filesystem boundary.
6. Use subsequent archive entries, application processing, or post-extraction workflows to read from or write through the hardlink.
7. Exfiltrate sensitive file contents, overwrite application or build files, or modify files that enable persistence or follow-on code execution.

How to detect it

To determine whether exploitation already occurred, focus on systems that accepted or extracted tar archives from untrusted or semi-trusted sources while running node-tar 7.5.7 or earlier. Review application upload logs, API request logs, object storage access logs, CI/CD job logs, artifact ingestion records, and endpoint file telemetry around archive extraction events. Look for tar archives containing hardlink entries, especially hardlinks whose targets are absolute paths or relative paths that escape the extraction directory. If archives are retained, inspect them with tooling that shows link metadata and flag entries of type hardlink with suspicious link targets. On endpoints, review file creation and modification events where the process performing extraction modified files outside expected workspace or temporary extraction paths. Pay particular attention to writes to application configuration, package files, startup scripts, SSH files, credential stores, shell profiles, cron/systemd locations, CI workspace configuration, and deployment artifacts. Correlate suspicious archive uploads with subsequent authentication anomalies, secret access, unexpected build output changes, configuration drift, or process execution from recently extracted content. Because exploitation can be target-specific and may leave few fixed strings, absence of these artifacts does not prove non-exploitation if archive samples and detailed filesystem telemetry are unavailable.

• node_modules/tar/package.json
• "version": "7.5.7"
• "version":"7.5.7"
• "tar@7.5.7"
• tar@7.5.7
• link to /etc/passwd
• link to /etc/shadow
• link to /root/.ssh/authorized_keys
• link to /root/.ssh/id_rsa
• link to /home/*/.ssh/authorized_keys
• link to ../../
• link to ../../../
• /etc/passwd
• /etc/shadow
• /root/.ssh/authorized_keys
• /root/.ssh/id_rsa
• authorized_keys
• .npmrc
• .env
• package.json
• package-lock.json
• yarn.lock
• pnpm-lock.yaml

What your security team should do

• Prioritize patching internet-facing services, file upload processors, artifact ingestion systems, CI/CD runners, developer portals, and automation that extracts user-controlled tar archives.
• Upgrade node-tar to 7.5.8 or later and rebuild all affected applications, images, and packaged artifacts rather than only updating source manifests.
• Search code repositories and dependency lockfiles for transitive uses of node-tar 7.5.7 or earlier, including tools that bundle their own Node.js dependencies.
• Temporarily block or quarantine untrusted tar archive processing where the dependency cannot be upgraded immediately.
• Add archive security controls that reject hardlinks and symlinks unless explicitly required and safely validated.
• Run extraction workloads with least privilege in disposable sandboxes or containers without access to secrets, host paths, or deployment credentials.
• Review recent archive submissions and extraction logs for suspicious hardlink use, references to sensitive absolute paths, or unexpected writes outside normal extraction directories.
• Add regression tests for path traversal, symlink, and hardlink archive edge cases to prevent reintroduction of unsafe extraction behavior.