CVE-2024-12905

What it actually does

The flaw is a link-following and path-traversal vulnerability in the Node.js tar-fs package during tar archive extraction. A crafted tar archive can contain entries or symbolic/hard links that resolve outside the intended extraction directory, allowing the extraction process to write or overwrite files at attacker-controlled filesystem paths. The primary impact is integrity compromise: arbitrary file write in the context and permissions of the process performing extraction. Affected versions are tar-fs 0.0.0 before 1.16.4, 2.0.0 before 2.1.2, and 3.0.0 before 3.0.8.

Why it matters to the business

Applications, CI/CD jobs, developer tools, package managers, upload pipelines, or backend services that extract untrusted tar files with vulnerable tar-fs versions may allow attackers to overwrite configuration, application, credential, startup, or deployment files. This can lead to service disruption, tampered builds, persistence, credential exposure through overwritten access controls, or follow-on code execution if the attacker can overwrite a file that is later executed or trusted. Although it is not listed in CISA KEV and is not known to be used in ransomware campaigns, public exploit availability and the age of the issue increase the likelihood that attackers and automated scanners can weaponize it in exposed archive-processing workflows.

How an attack unfolds

An attacker first identifies an application or workflow that accepts, downloads, or processes tar archives using a vulnerable version of tar-fs. The attacker crafts a tar file containing path traversal entries, absolute paths, or symbolic/hard links that cause file resolution to escape the intended extraction directory. When the vulnerable application extracts the archive, tar-fs follows or resolves the malicious paths incorrectly and writes attacker-supplied content outside the destination directory. The attacker then targets files that create operational impact or follow-on compromise, such as application configuration files, build artifacts, shell profiles, service startup files, authorized_keys files, cron entries, or files later consumed by another process. Successful exploitation depends on filesystem permissions of the extraction process and whether the overwritten file is subsequently used, loaded, executed, or trusted.

How to fix it

Upgrade tar-fs to a fixed version on the appropriate release line: 1.16.4 or later for the 1.x line, 2.1.2 or later for the 2.x line, and 3.0.8 or later for the 3.x line. The upstream Git fix is associated with commit a1dd7e7c7f4b4a8bd2ab60f513baca573b44e2ed. Regenerate lockfiles after upgrading and ensure transitive dependencies are also updated through npm, yarn, pnpm, or the relevant package manager. If immediate upgrade is not possible, avoid extracting untrusted tar archives, run archive extraction in a sandbox or isolated container with a restricted filesystem, extract as a low-privilege user, deny writes outside a temporary working directory, reject archive entries containing absolute paths, parent-directory traversal, symbolic links, or hard links, and perform canonical path validation before each write.

How to confirm the fix worked

Confirm that dependency inventories, SBOMs, package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed node_modules trees no longer contain vulnerable tar-fs versions. Validate that tar-fs resolves to 1.16.4 or later, 2.1.2 or later, or 3.0.8 or later depending on the branch in use. Run software composition analysis across source repositories, build images, containers, serverless bundles, and packaged applications. Where safe, perform a controlled regression test using a tar archive with traversal and symlink entries and verify extraction rejects the archive or confines all writes to the intended directory. Review application behavior to ensure uploaded or downloaded archives are extracted only in isolated temporary directories and with least-privilege permissions.

Typical attack path

1. Identify a service, build process, CLI tool, or automation workflow that extracts tar archives using tar-fs.
2. Confirm or infer that the environment uses a vulnerable tar-fs version: before 1.16.4, 2.1.2, or 3.0.8 depending on the major release line.
3. Create a malicious tar archive containing traversal paths, absolute paths, or link entries that resolve outside the intended extraction directory.
4. Submit, upload, or otherwise cause the target workflow to extract the archive.
5. Use the arbitrary file write primitive to overwrite a file accessible to the extraction process.
6. Trigger or wait for the overwritten file to be read, trusted, deployed, or executed by another process.
7. Leverage the resulting tampering for persistence, configuration manipulation, service disruption, credential access, or potential code execution.

How to detect it

To determine whether exploitation may have already occurred, review logs and artifacts from systems or applications that extract tar archives. Focus on upload handlers, artifact ingestion services, package processing jobs, CI/CD runners, container build systems, developer tooling, and background workers. Look for tar extraction events followed by file creation or modification outside expected temporary extraction directories. File integrity monitoring, EDR telemetry, auditd, Linux process accounting, container runtime logs, CI job logs, web access logs, and application logs are the most useful sources. Investigate archive filenames or extracted entry names containing parent-directory traversal, absolute paths, or link metadata. Correlate suspicious archive submissions with subsequent modifications to startup scripts, service files, application configuration, SSH authorized_keys, shell profiles, cron locations, build scripts, package manifests, or deployed application files. Also search dependency artifacts to identify exposure, including package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and node_modules/tar-fs/package.json entries showing vulnerable versions. Because exploitation results in arbitrary file write rather than a fixed network signature, high-confidence detection usually requires correlating archive extraction with unexpected filesystem writes by the same process identity.

• node_modules/tar-fs/index.js
• node_modules/tar-fs/package.json
• "tar-fs": "0.
• "tar-fs": "1.16.3"
• "tar-fs": "2.0.
• "tar-fs": "2.1.0"
• "tar-fs": "2.1.1"
• "tar-fs": "3.0.0"
• "tar-fs": "3.0.1"
• "tar-fs": "3.0.2"
• "tar-fs": "3.0.3"
• "tar-fs": "3.0.4"
• "tar-fs": "3.0.5"
• "tar-fs": "3.0.6"
• "tar-fs": "3.0.7"
• ../
• ..\\
• /etc/cron.d/
• /etc/systemd/system/
• /root/.ssh/authorized_keys
• .ssh/authorized_keys
• .bashrc
• .profile
• package.json
• postinstall

What your security team should do

• Prioritize discovery of applications, build pipelines, CI jobs, artifact processors, and backend services that extract tar archives from untrusted or semi-trusted sources.
• Upgrade tar-fs to 1.16.4+, 2.1.2+, or 3.0.8+ and rebuild/redeploy affected applications and container images.
• Search dependency manifests and lockfiles for vulnerable tar-fs versions, including transitive dependencies pulled in by higher-level packages.
• Add archive validation controls that reject absolute paths, parent-directory traversal, symbolic links, and hard links before extraction.
• Run extraction workloads with least privilege inside sandboxed directories or containers that cannot write to sensitive host paths.
• Review recent archive-processing activity for unexpected file writes outside extraction directories, especially around uploaded archives or automated downloads.
• Add tests to CI that verify archive extraction libraries cannot write outside the configured destination directory.
• Monitor advisories for downstream packages that bundle or depend on tar-fs and ensure patched versions are propagated through the dependency tree.