CVE-2025-48387

What it actually does

tar-fs before 3.0.9, 2.1.3, and 1.16.5 can fail to constrain extracted archive entries to the intended destination directory. A specially crafted tar archive can cause the extractor to write files outside the caller-specified extraction root, resulting in arbitrary file overwrite or creation with the privileges of the process performing extraction. The primary security impact is integrity compromise: attacker-controlled archive content may replace application files, configuration, startup scripts, keys, or other writable paths. Direct confidentiality and availability impact depend on what filesystem locations are writable and how the affected application uses the extracted files.

Why it matters to the business

Applications or services that accept, download, unpack, or process untrusted tar archives using vulnerable tar-fs versions may allow an attacker to tamper with files outside the intended upload or extraction area. In business terms, this can lead to corrupted application behavior, planted persistence files, modified configuration, credential exposure if overwritten files influence later execution, and potential service compromise if the overwritten path is executed or loaded. The issue is not currently in the CISA Known Exploited Vulnerabilities catalog, is not flagged as ransomware-used, and has a low EPSS score, but it has been public for over a year, so remediation should be treated as routine dependency hygiene with higher urgency for internet-facing archive ingestion, CI/CD, package processing, backup restore, or file import workflows.

How an attack unfolds

An attacker first identifies a workflow that extracts tar files using a vulnerable tar-fs release, such as a web upload feature, build pipeline, package importer, file synchronization component, or automated archive processor. The attacker then supplies a malicious tarball containing entries whose names or metadata cause extraction paths to resolve outside the intended destination directory. When the application extracts the archive, tar-fs writes attacker-controlled content to an unintended filesystem location that is writable by the process. If the attacker can target sensitive paths, they may overwrite configuration, application source, scripts, scheduled task inputs, web-accessible files, or other files later consumed by the application. Follow-on impact depends on the target path: the result may be data tampering, persistence, execution during a later application restart or build step, or disruption of normal operations.

How to fix it

Upgrade tar-fs to a patched release: 3.0.9 or later for the 3.x line, 2.1.3 or later for the 2.x line, or 1.16.5 or later for the 1.x line. If consuming directly from the upstream Git repository, use a version containing commit 3c6eddb6008d14f4ca83a439dd432263d29ecb0f or a later release. Regenerate lockfiles and redeploy all applications, containers, serverless packages, and build images that bundle the vulnerable dependency. If immediate upgrade is not possible, avoid extracting untrusted tar archives, isolate extraction in a temporary sandbox with least-privilege filesystem permissions, prevent the extraction process from writing to application, system, or startup paths, validate canonicalized output paths before writing, and use the tar-fs ignore option to ignore non-file and non-directory entries as recommended by the project. Treat these mitigations as temporary; dependency upgrade is the preferred fix.

How to confirm the fix worked

Confirm exposure by inspecting dependency manifests and lockfiles for tar-fs versions earlier than 3.0.9, 2.1.3, or 1.16.5, including transitive dependencies. Use package-manager tooling such as npm ls tar-fs, yarn why tar-fs, pnpm why tar-fs, software composition analysis, SBOM queries, and container image scans. Validate remediation by confirming the deployed artifact, not only the source repository, contains a patched tar-fs version. Functional validation should include a safe regression test that extracts a benign archive containing traversal-like entry names into a disposable directory and verifies no files are created outside that directory. Also verify runtime hardening: extraction processes should run with restricted filesystem permissions and should not have write access to sensitive application or operating system paths.

Typical attack path

1. Find an application, service, pipeline, or tool that accepts or retrieves tar archives from an untrusted or semi-trusted source.
2. Confirm or infer that the workflow uses a vulnerable tar-fs version before 3.0.9, 2.1.3, or 1.16.5.
3. Create a tar archive containing path traversal-style entries or archive metadata that resolves outside the intended extraction directory.
4. Submit, upload, or cause the vulnerable workflow to process the crafted archive.
5. During extraction, cause attacker-controlled files to be written outside the configured destination directory.
6. Leverage the overwritten or newly created files for application tampering, persistence, follow-on code execution, or operational disruption depending on writable paths and downstream behavior.

How to detect it

Look for evidence that untrusted tar archives were processed by applications using vulnerable tar-fs versions and that files were written outside expected extraction directories. Useful sources include application upload/import logs, API gateway and web access logs for archive submissions, CI/CD job logs, package ingestion logs, container build logs, endpoint file creation telemetry, EDR process/file events for Node.js processes, and filesystem audit logs. Search archive names, extraction logs, and preserved uploaded files for traversal patterns such as ../, ..\, absolute Unix paths, Windows drive paths, UNC paths, or suspicious tar metadata. Correlate extraction times with unexpected writes to application directories, configuration directories, startup locations, web roots, SSH directories, cron/systemd locations, or build scripts. On Linux, auditd or EDR file-write events by node, npm, yarn, pnpm, or application-specific Node.js processes are especially useful. On Windows, review Sysmon Event ID 11 file creation events and process lineage involving node.exe. Because public reporting does not identify a stable malware family or campaign-specific indicator for this issue, detection should focus on behavioral artifacts: malicious archive entries, out-of-root file creation, unexpected modification of executable/configuration files, and process activity following extraction.

• ../
• ..\\
• /etc/
• /root/.ssh/
• /home/*/.ssh/
• /var/spool/cron/
• /etc/cron.d/
• /etc/systemd/system/
• /usr/local/bin/
• /var/www/
• C:\\Windows\\
• C:\\Users\\
• C:\\ProgramData\\
• %APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\
• \\\\
• tar-fs
• node
• node.exe
• npm
• npm.exe
• yarn
• yarn.exe
• pnpm
• pnpm.exe
• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• node_modules/tar-fs/package.json

What your security team should do

• Inventory all applications, build systems, file-processing services, and containers that include tar-fs, especially those processing user-supplied or externally sourced tar archives.
• Prioritize patching internet-facing upload/import features, CI/CD systems, package ingestion services, backup/restore utilities, and automation that extracts archives from third parties.
• Upgrade tar-fs to 3.0.9, 2.1.3, or 1.16.5 or later, then rebuild and redeploy affected artifacts so vulnerable transitive copies are removed.
• Add dependency policy checks to block vulnerable tar-fs versions in manifests, lockfiles, SBOMs, and container images.
• Harden archive extraction by canonicalizing destination paths, rejecting entries that resolve outside the extraction root, using temporary isolated directories, and applying least-privilege filesystem permissions.
• Review recent archive-processing activity for suspicious traversal entries and unexpected file writes near the time archives were extracted.
• If evidence of exploitation is found, preserve the submitted archive, process logs, filesystem timestamps, and affected artifacts; then rotate any secrets or credentials that may have been overwritten, exposed, or influenced by tampered configuration.