CVE-2025-69874: 
JavaScript vulnerability analysis and mitigation

CVE-2025-69874 is a path traversal ("Zip Slip") vulnerability in the nanotar npm package, affecting all versions through 0.2.0. The flaw exists in the parseTar() and parseTarGzip() functions, allowing remote attackers to write arbitrary files outside the intended extraction directory via a crafted tar archive containing path traversal sequences (e.g., ../../../). The vulnerability was discovered on 2025-12-17 by Ethan Taebeom Kim of Cremit and published by MITRE on 2026-02-11. It carries a CVSS v3.1 base score of 9.8 (Critical) per Feedly/NVD, though the GitHub Advisory Database rates it 6.9 (Moderate) under CVSS v4 (GitHub Advisory, Researcher Disclosure).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). In src/parse.ts, the parseTar() function reads file names directly from tar archive headers — both from the standard 100-byte name field and from extended PAX headers (path and linkpath fields) — without any validation or sanitization. Path traversal sequences such as ../ and absolute paths like /etc/passwd pass through unchanged, and the raw, unsanitized name field is returned in TarFileItem objects. Any application that uses this name to construct output file paths (the standard extraction pattern) is therefore vulnerable. The attack follows the well-known "Zip Slip" pattern, previously seen in tar-fs (CVE-2024-12905) and adm-zip (CVE-2018-1002204) (Researcher Disclosure, GitHub Advisory).

Successful exploitation allows an attacker to write arbitrary files to any location accessible by the process running nanotar, including overwriting critical system files, configuration files, SSH authorized keys, cron jobs, or web shells — potentially leading to remote code execution, persistent backdoor access, or data corruption. The vulnerability requires no authentication or user interaction and is exploitable over the network with low complexity, resulting in high integrity and availability impact. Applications using nanotar in web file upload handlers, CI/CD pipelines, or build tools are particularly at risk, as a malicious archive could compromise the entire host system (Researcher Disclosure, GitHub Advisory).

A public proof-of-concept (PoC) is available in the researcher's disclosure repository, demonstrating successful exploitation using nanotar's own createTar() API to craft a malicious archive and parseTar() to trigger the traversal (Researcher Disclosure). No in-the-wild exploitation has been confirmed at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.23% (0.002270), indicating a currently low but non-negligible probability of exploitation in the next 30 days (GitHub Advisory). No specific threat actor attribution has been reported.

1. Reconnaissance: Identify applications that accept tar archive uploads or process tar archives using nanotar (versions ≤ 0.2.0). Target web applications, CI/CD pipelines, or build tools that use parseTar() or parseTarGzip() for extraction.
2. Craft malicious archive: Use nanotar's own createTar() API or a custom script to create a tar archive with a file entry whose name field contains a path traversal sequence, e.g., ../../../tmp/pwned.txt or ../../../root/.ssh/authorized_keys.

   import { createTar } from 'nanotar';
   const maliciousTar = createTar([{
     name: '../../../tmp/pwned.txt',
     data: new TextEncoder().encode('Path traversal successful')
   }]);

3. Deliver the archive: Upload or supply the crafted tar archive to the target application through any available file upload endpoint, API, or artifact delivery mechanism.
4. Trigger extraction: The application calls parseTar() or parseTarGzip() on the archive. The unsanitized name field is used to construct the output path, e.g., join('/app/uploads/extracted', '../../../tmp/pwned.txt'), which resolves to /tmp/pwned.txt.
5. Achieve objective: The file is written outside the intended extraction directory. Depending on the target path and process permissions, this can result in arbitrary file overwrite, SSH key injection, cron job backdoor, web shell placement, or remote code execution (Researcher Disclosure).

• File System: Unexpected files created outside designated extraction directories (e.g., /tmp/, /etc/cron.d/, /root/.ssh/, web root directories); new or modified authorized_keys files; unexpected cron job entries; web shells in application directories.
• Logs: Application logs showing tar extraction operations followed by file write errors or unexpected file paths; Node.js process errors referencing path traversal sequences (../) in file names during archive extraction.
• Process: Unusual child processes spawned by the Node.js application server (e.g., reverse shells, curl, wget) after a tar archive upload event.
• Network: Unexpected outbound connections from the application server following a file upload event, potentially indicating post-exploitation activity such as reverse shell callbacks (Researcher Disclosure).

The nanotar maintainers released version 0.3.0 on 2026-02-11, which is the recommended patched version; all users should upgrade immediately from any version ≤ 0.2.0 (nanotar GitHub). As a workaround for applications that cannot immediately upgrade, validate all extracted file paths before writing by resolving the full path and confirming it remains within the intended destination directory:

const targetPath = path.resolve(destDir, file.name);
if (!targetPath.startsWith(path.resolve(destDir) + path.sep)) {
  throw new Error(`Path traversal attempt blocked: ${file.name}`);
}

Additionally, consider restricting file extraction operations to a sandboxed directory with minimal filesystem permissions, and implement input validation to reject tar archives containing ../ sequences or absolute paths before processing (Researcher Disclosure, GitHub Advisory).

The vulnerability was discovered and disclosed by Ethan Taebeom Kim of Cremit, who published a detailed technical write-up including a working PoC (Researcher Disclosure). The nanotar maintainers responded promptly by releasing version 0.3.0 on the same day as the CVE publication (2026-02-11) (nanotar GitHub). Coverage was picked up by security aggregators including The Hacker Wire and INCIBE-CERT, reflecting moderate community interest given nanotar's significant npm download volume (over 815,000 weekly downloads).