How Archive Path Traversal Happens in Node.js and How to Fix It

How Archive Path Traversal Happens in Node.js and How to Fix It

The Hidden Risk in Your Test Infrastructure

Test tooling rarely gets the same security scrutiny as production application code — but it lives in the same dependency graph, and its transitive dependencies can carry critical vulnerabilities into your project. That is exactly what happened here.

Trivy's static analysis scanner flagged yarn.lock in the Storybook monorepo with CVE-2026-53486, a critical path traversal vulnerability in the decompress library. The vulnerability did not arrive through a direct dependency. It arrived as a transitive dependency of @vitest/browser 4.1.5 — a package used for browser-based test execution. The fix was a targeted upgrade of five vitest-family packages across three package.json files.

The Vulnerability Explained

What Is Archive Path Traversal (Zip Slip)?

The decompress library is a popular Node.js utility for extracting .zip, .tar, .tar.gz, and other archive formats. Its job is simple: read entries from an archive and write them to a target directory.

The vulnerability arises when the library does not validate whether an archive entry's path, after resolution, still points inside the target directory. An attacker who controls the archive content can craft entries like:

../../../../etc/cron.d/malicious
../../../home/user/.ssh/authorized_keys

Or even absolute paths:

/etc/passwd
/usr/local/bin/node

When decompress resolves these paths and writes the extracted bytes, the resulting file lands outside the intended extraction directory. This class of vulnerability is sometimes called Zip Slip (named after a coordinated disclosure by Snyk in 2018), and it affects any extraction library that fails to canonicalize output paths.

CVE-2026-53486 is a new instance of this pattern in a version of decompress that was pulled in transitively by @vitest/browser 4.1.5.

The Vulnerable Dependency Chain

The vulnerable path in the Storybook repository looked like this:

@vitest/browser@4.1.5
  └── (transitive) decompress@<patched-version>
        └── ❌ No path boundary check before file.write()

Because decompress did not verify that the resolved output path was contained within the target directory, any code path that called decompress() on attacker-influenced archive data was exploitable.

Concrete Attack Scenario

Consider a CI/CD pipeline or a developer machine running Storybook's test suite. If the test runner fetches a browser binary, a fixture archive, or any compressed asset from an untrusted or compromised source, and that asset is processed by decompress via the @vitest/browser internals, an attacker-controlled entry such as:

../../../.npmrc

…could overwrite the developer's npm configuration file, injecting a malicious registry URL. A more severe variant could target:

../../../../usr/local/lib/node_modules/some-global-tool/index.js

…overwriting a globally installed tool's entry point with arbitrary code that executes the next time that tool runs.

Even in environments where the extraction target is sandboxed, symbolic link entries (e.g., a .tar entry of type symlink pointing to /etc) can be used to escape the sandbox in a second extraction step.

The Fix

What Changed

The fix upgrades five vitest-family packages from ^4.1.5 to ^4.1.6 (and the beta channel to 5.0.0-beta.3) across three package.json files. Version 4.1.6 of @vitest/browser and its sibling packages resolve to a patched version of decompress that validates entry paths before writing.

code/addons/vitest/package.json

- "@vitest/browser-playwright": "^4.1.5",
- "@vitest/runner": "^4.1.5",
+ "@vitest/browser-playwright": "^4.1.6",
+ "@vitest/runner": "^4.1.6",

- "vitest": "^4.1.5"
+ "vitest": "^4.1.6"

code/package.json

- "@vitest/browser": "^4.1.5",
- "@vitest/browser-playwright": "^4.1.5",
- "@vitest/coverage-istanbul": "^4.1.5",
- "@vitest/coverage-v8": "^4.1.5",
+ "@vitest/browser": "^4.1.6",
+ "@vitest/browser-playwright": "^4.1.6",
+ "@vitest/coverage-istanbul": "^4.1.6",
+ "@vitest/coverage-v8": "^4.1.6",

- "vitest": "^4.1.5"
+ "vitest": "^4.1.6"

package.json (root)

- "vitest": "^4.1.5"
+ "vitest": "^4.1.6"

Why All Five Packages?

The vitest ecosystem packages (@vitest/browser, @vitest/browser-playwright, @vitest/coverage-istanbul, @vitest/coverage-v8, @vitest/runner) are versioned in lockstep. Upgrading only one while leaving the others at 4.1.5 would still allow yarn to resolve the old, vulnerable transitive dependency through whichever 4.1.5 package remained. Upgrading all five simultaneously ensures that yarn.lock resolves a single consistent — and patched — closure of transitive dependencies.

How the Patched decompress Fixes the Problem

The corrected extraction logic in the patched decompress version performs a path canonicalization check before any file write or symlink creation:

// Conceptual representation of the fix in decompress
const targetDir = path.resolve(outputDirectory);
const outputPath = path.resolve(targetDir, entryPath);

if (!outputPath.startsWith(targetDir + path.sep)) {
  throw new Error(`Path traversal detected: ${entryPath}`);
}

// Safe to write
fs.writeFileSync(outputPath, entryData);

By calling path.resolve() on both the target directory and the combined target+entry path, and then asserting that the result starts with the target directory prefix (including a trailing separator to prevent prefix-match bypasses like /tmp/safe-dir-evil), the library ensures that no entry — regardless of how many ../ components it contains — can escape the intended extraction root.

Key Takeaways

• Test-only dependencies are not automatically safe: @vitest/browser is a devDependency, but its transitive dependency decompress carried a critical CVE that affected any developer or CI runner processing archives through that package.
• yarn.lock is your ground truth for transitive vulnerabilities: Trivy flagged yarn.lock specifically because that file captures the exact resolved versions of all transitive packages — including the vulnerable decompress build.
• Upgrading one package in a lockstep ecosystem is not enough: All five @vitest/* packages needed simultaneous bumps from 4.1.5 → 4.1.6 to ensure yarn resolved a consistent, patched dependency closure.
• Path traversal in archive extraction is a solved problem: The fix is a two-line path.resolve() + startsWith() check. Any extraction library that omits this check should be considered unsafe regardless of its popularity.
• Automated scanning caught what code review would not: No human reviewer auditing a package.json diff for a version bump would have traced the decompress transitive dependency path. Static analysis tooling is essential for this class of vulnerability.

How Orbis AppSec Detected This

• Source: Archive entry paths within compressed files processed by the decompress transitive dependency, reachable through @vitest/browser@4.1.5 internals
• Sink: decompress's file-write routine, which accepted unsanitized entry paths and resolved them relative to the process working directory rather than the declared target directory
• Missing control: No path.resolve() canonicalization or startsWith(targetDir) boundary check before writing extracted file content or creating symbolic links
• CWE: CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ("Path Traversal")
• Fix: Upgraded @vitest/browser, @vitest/browser-playwright, @vitest/coverage-istanbul, @vitest/coverage-v8, and vitest from ^4.1.5 to ^4.1.6 across all three package.json files, pulling in a patched decompress transitive dependency that validates entry paths before extraction.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-53486 is a sharp reminder that the security boundary of your application extends all the way to the leaves of your dependency tree — including test infrastructure. A critical path traversal vulnerability in decompress, surfaced through the @vitest/browser 4.1.5 dependency chain, could have allowed an attacker to write arbitrary files outside the intended extraction directory on any developer machine or CI runner processing a crafted archive.

The fix was surgical: five version bumps across three package.json files, regenerating yarn.lock to pull in a patched transitive dependency. But the detection required automated tooling — specifically Trivy scanning yarn.lock and tracing the transitive dependency graph back to the vulnerable decompress version.

Archive extraction is one of the oldest classes of path traversal vulnerabilities, and the mitigation has been well understood for years: canonicalize paths, check boundaries, reject traversals. When choosing or auditing archive libraries in your Node.js projects, verify that the library performs this check before you depend on it.