CVE-2018-20834

What it actually does

node-tar versions before 4.4.2, except the separately patched 2.2.2 release, mishandle tar archives that combine a hardlink entry with a later regular file entry using the same archive path. During extraction, a malicious archive can cause node-tar to treat the hardlink as a reference to an existing filesystem object and then overwrite that existing object with attacker-controlled file contents. The primary impact is integrity compromise: files writable by the extracting process can be modified outside the attacker's intended archive contents, potentially affecting application code, configuration, scripts, dependency files, or other sensitive local files. The CVSS vector indicates network-reachable exploitation can occur where an application accepts and extracts attacker-supplied tarballs without authentication or user interaction, but the practical blast radius depends on the extraction directory, process privileges, filesystem permissions, and whether extracted files are later executed or trusted.

Why it matters to the business

Organizations using vulnerable node-tar versions in package managers, build systems, CI/CD tooling, artifact ingestion, backup restore workflows, or applications that process uploaded tarballs may allow untrusted archive content to alter trusted files. This can lead to compromised builds, tampered application behavior, broken deployments, loss of configuration integrity, or a stepping stone to code execution if overwritten files are later loaded or executed. The issue is old and not listed in CISA KEV, and EPSS is relatively low, but exploit techniques are public and the library is commonly embedded transitively in JavaScript tooling, so legacy applications and pinned dependencies remain the main risk.

How an attack unfolds

An attacker first identifies a service, automation workflow, or developer/build process that extracts tar archives using a vulnerable node-tar release. They craft a tarball containing a hardlink entry whose target points to an existing file that the extraction process can write to, followed later in the archive by a normal file entry with the same path as the hardlink. When the vulnerable extractor processes the archive, it creates or resolves the hardlink relationship and then writes the later regular file content through that path, replacing the contents of the existing file. The attacker chooses the target based on the execution context: configuration files for behavior changes, scripts or JavaScript files for later execution, package metadata for dependency manipulation, or application assets for defacement or disruption. Successful exploitation does not require credentials if the vulnerable extraction path is exposed to unauthenticated archive input, but it does require that the targeted file is writable by the process performing extraction.

How to fix it

Upgrade node-tar to version 4.4.2 or later. If using the 2.x branch, use the patched 2.2.2 release. For source builds from isaacs/node-tar, ensure the code includes fix commit 7ecef07da6a9e72cc0c4d0c9c6a8e85b6b52395d. Because node-tar is often pulled in transitively, review package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, vendored dependencies, and container images for vulnerable resolved versions. Rebuild and redeploy artifacts after dependency updates rather than only changing manifest constraints. As defense in depth, never extract untrusted archives with elevated privileges; extract into newly created, empty, sandboxed directories; reject or strip hardlinks and symlinks from untrusted archives; enforce path and type validation before writing files; run extraction under a dedicated low-privilege account; and prevent extracted content from overwriting source code, configuration, executables, or shared caches.

How to confirm the fix worked

Confirm dependency resolution shows node-tar 4.4.2 or later, or 2.2.2 if intentionally on the 2.x line. Use package manager tooling such as npm ls tar, yarn why tar, pnpm why tar, software composition analysis, and container image scans to locate all instances, including transitive and vendored copies. Inspect lockfiles for resolved tar package versions lower than 4.4.2, excluding 2.2.2. Validate runtime images and build agents, not just source repositories. Where feasible, run a safe regression test in a disposable environment using an archive with hardlink-plus-file ordering to confirm extraction does not overwrite a preexisting protected test file. Review application code to verify untrusted archives are extracted only into empty temporary directories and that hardlink entries are rejected or safely handled.

Typical attack path

1. Find an application, package workflow, CI job, or artifact ingestion process that accepts tar archives and extracts them with a vulnerable node-tar version.
2. Determine or infer files that already exist and are writable by the extraction process, such as files inside a workspace, application directory, cache, or build output path.
3. Create a malicious tarball containing a hardlink entry associated with the target file and a later regular file entry with the same archive name.
4. Submit or introduce the archive through the exposed upload, dependency, package, restore, or build-artifact mechanism.
5. Allow the vulnerable extraction logic to process the hardlink and later file entry, causing attacker-controlled contents to overwrite the existing file.
6. Wait for the overwritten file to be trusted, loaded, packaged, executed, deployed, or otherwise used by the application or build system.

How to detect it

Look for evidence that untrusted tar archives were extracted and followed by unexpected file modifications. Useful sources include application upload logs, API gateway and web server access logs for archive submissions, CI/CD job logs, package publishing or artifact ingestion logs, endpoint file integrity monitoring, EDR telemetry, shell history on build hosts, container build logs, and auditd or operating-system file write events. Focus on sequences where a .tar, .tgz, or .tar.gz file was received or processed shortly before changes to source files, package metadata, scripts, configuration files, executable files, or deployment artifacts. In npm or Node.js environments, investigate projects with node_modules/tar versions below 4.4.2 other than 2.2.2, especially if they also handle uploaded or third-party archives. Forensic review should include tar entry listings from retained uploaded artifacts, looking for hardlink entries followed by regular file entries with the same name, or hardlink targets referencing files expected to preexist in the extraction workspace. There are no universal network indicators for this issue because exploitation is archive-content based and target paths are environment-specific.

• node_modules/tar/package.json
• "name": "tar"
• "version": "4.4.1"
• "version": "4.4.0"
• "version": "4.3.
• "version": "4.2.
• "version": "4.1.
• "version": "4.0.
• "version": "3.
• "version": "2.2.1"
• "version": "2.2.0"
• .tar.gz
• .tgz
• tar: hard link
• typeflag '1'
• typeflag=1
• linkname

What your security team should do

• Inventory all applications, CI/CD workers, package-processing services, and artifact ingestion workflows that use node-tar directly or transitively.
• Prioritize remediation for internet-facing or unauthenticated archive upload/extraction paths, build systems that consume third-party packages, and processes running with broad filesystem write permissions.
• Upgrade node-tar to 4.4.2 or later, or 2.2.2 on the 2.x branch, and rebuild affected deployments and containers.
• Add policy controls to reject hardlinks and symlinks in untrusted tar archives unless there is a documented business need and safe extraction controls are in place.
• Run extraction workloads as low-privilege users in isolated temporary directories with no write access to application code, system directories, shared caches, or deployment configuration.
• Search historical logs and build artifacts for suspicious archive extraction events followed by unexpected file changes in workspaces, package directories, or application directories.
• Add SCA rules or dependency governance checks to block node-tar versions before 4.4.2 except 2.2.2 in new builds.
• Because public exploit knowledge exists even though the issue is not in KEV, treat lingering exposure as technical debt that should be removed during normal patch cycles, with accelerated handling for systems processing untrusted archives.