Node.js Archive Extraction Risks: @xhmikosr/decompress and Symlink Chains (2026)

When “extract to a folder” escapes the folder

Node services that call decompress(input, output) (from @xhmikosr/decompress or the legacy decompress package on npm) look harmless: unzip a tarball, write files under ./uploads/extracted. CVE-2026-101894 and related advisories show a harder problem—symlink chains inside archives that trick sequential extraction into resolving paths outside the intended output directory.

That is not theoretical supply-chain trivia. CI pipelines, container builders, admin “import theme” wizards, and SaaS “upload zip” features have all been classes of real-world extractors. Read/write outside the destination can become config overwrite, credential theft, or remote code execution when the escaped path hits something executable on next boot.

What changed after CVE-2026-53486

Maintainers hardened @xhmikosr/decompress against classic Zip Slip / path traversal. CVE-2026-101894 documents a bypass via chained symlink entries—lexical checks on each member path are insufficient when the kernel follows links across steps. Fixed lines include 10.2.2 (10.x) and 11.1.4 (11.x).

The older decompress package (kevva) is widely considered unmaintained for this class of fix—teams should migrate to @xhmikosr/[email protected]+, not bump a patch level and hope.

| Package line | Risky (examples) | Patched direction | |--------------|------------------|-------------------| | @xhmikosr/decompress 11.x | 11.0.0 – 11.1.3 | ≥ 11.1.4 | | @xhmikosr/decompress 10.x | < 10.2.2 | ≥ 10.2.2 | | decompress (legacy) | ≤ 4.2.1 | Migrate package |

Mechanism-focused PoC and lab tooling: CVE-2026-101894 on pocbit.org.

Who should care in your org

| Team | Why | |------|-----| | AppSec / SCA | Lockfiles and SBOMs listing vulnerable decompress versions | | Platform / DevOps | Custom importers, Helm chart unpackers, artifact promotion jobs | | Backend (Node) | Any route that accepts .tar, .zip, .tgz from users or webhooks | | SOC | Unusual writes under /etc, ~/.ssh, or app roots after upload spikes |

A public package.json on the internet is not the same as exploitable upload—but it is a patch prioritization signal. Many incidents start with “we did not know that microservice extracted archives with a five-year-old dependency.”

Hardening beyond npm version bumps

1. Upgrade decompress family packages everywhere they appear (direct and transitive—run npm ls @xhmikosr/decompress and audit legacy decompress).
2. Never extract untrusted archives as root or as the same user that owns production config.
3. Prefer out-of-process extraction in disposable containers with read-only upper layers where feasible.
4. Reject uploads at the edge when MIME/extension does not match business need.
5. Log extract jobs with source user, archive hash, and destination path; alert on writes outside the job directory.

For broader dependency hygiene, pair this with supply chain security for open source and reading vendor advisories.

Scanner vs lab proof

Automated check modes in public PoCs often mean: “we saw a vulnerable version string in a leaked lockfile” or “an upload endpoint returned 2xx.” That is not proof your production worker actually invoked vulnerable decompress on attacker bytes.

Authoritative validation is a local lab: install the vulnerable line, run extraction against a known symlink-chain test archive, confirm escape, then repeat on the patched version and confirm containment. Document both runs in your change ticket.

Defenders should not treat exploited.txt from mass scans as “we are owned”—treat it as “follow up on upload surface + dependency versions.”

Incident-shaped questions if you suspect abuse

• Did any service extract user-supplied archives in the last 30 days?
• Are there new files under /tmp, ~/.npm, or web roots with recent timestamps?
• Did CI publish artifacts from a job that processed external tarballs?
• Compare running container images to rebuilt images from patched lockfiles.

Rotate secrets if extraction ran as a privileged user and archives were not strictly trusted.

FAQ

We only use decompress in devDependencies

Transitive use in build tools still matters if CI executes them on untrusted input (fork PRs, cached artifacts). Scope the upgrade to every pipeline stage that unpacks archives.

Is switching to another unzip library enough?

Any replacement must enforce containment (realpath checks, no unsafe symlink follow, or extract in isolated namespaces). Library shopping without threat modeling repeats the same mistake.

Where to track new archive CVEs?

Use CVE Detector, GitHub GHSA feeds for @xhmikosr/decompress, and your internal SCA alerts. When pocbit publishes archive traversal PoCs, map them to services that extract, not only to “Node apps generically.”

Bottom line

Archive extraction is a filesystem privilege boundary. CVE-2026-101894 is a reminder that symlink semantics defeat naive string checks. Patch @xhmikosr/decompress, retire legacy decompress, isolate extract workers, and prove fixes in a lab before closing tickets.