CVE-2026-53486 is a critical-severity (CVSS 9.1) Path Traversal vulnerability in @xhmikosr/decompress. A fix is available for @xhmikosr/decompress — see the affected versions and patch details below.
decompress: Archive extraction can create files and links outside the target directory
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-53486.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-53486 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 389,824 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@xhmikosr/decompressnpmdecompressnpmDescription
Impact
When extracting an archive to a directory, a crafted archive can read or write files outside that directory. The flaw is in the code that writes the parsed entries, so it affects every format decompress handles: tar, tar.gz, tar.bz2, and zip by default, plus any others added through the plugins option.
A link (hardlink) or symlink entry is created without checking where its target points. A hardlink can be aimed at any file the running process can read; that file then appears inside the output directory and its contents are exposed. A symlink can point outside the output directory and redirect a later write.
The path containment check used a string prefix comparison (realPath.indexOf(outputPath) !== 0). Output /srv/out does not contain /srv/out-old, but the prefix comparison treats it as inside, so an entry can escape into a sibling directory whose name starts with the output directory name.
File modes were applied as mode & ~umask, which does not remove the setuid, setgid, or sticky bits. A crafted entry can create a setuid or setgid file. This matters when extraction runs as root, for example in CI, containers, or install scripts.
Any code that extracts archives from an untrusted or attacker-influenced source is affected. Archives are commonly downloaded before extraction, so this is reachable over the network in many setups.
Patches
Fixed in @xhmikosr/decompress 10.2.1 and 11.1.3. Link targets are now resolved and checked against the output directory, containment uses path.relative, and setuid, setgid, and sticky bits are removed.
The upstream decompress package is unmaintained, and all versions through its last release (4.2.1) have the same flaws. There is no upstream fix. Migrate to @xhmikosr/decompress 11.1.3 or later.
Workarounds
Extract only archives you trust. Run extraction as a non-root user so the mode issue cannot create a privileged file. After extracting, reject any symlink or hardlink that points outside the target and any file with unexpected mode bits.
Resources
- Related prior issue in the upstream project this package forks: CVE-2020-12265 / GHSA-qgfr-5hqp-vrw9
- Fix commits and releases:
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @xhmikosr/decompress | all versions | 10.2.1npm install @xhmikosr/decompress@10.2.1 |
| 📦npm | @xhmikosr/decompress | ≥ 11.0.0&&< 11.1.3 | 11.1.3npm install @xhmikosr/decompress@11.1.3 |
| 📦npm | decompress | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @xhmikosr/decompress, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @xhmikosr/decompress to 10.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-53486 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Red Hat Build of Keycloak, Red Hat Advanced Cluster Management (VolSync), Red Hat Hardened Images (dotnet8.0), and the Fedora/EPEL yarnpkg packages bundle the original, unmaintained npm decompress package (version 4.2.1 or earlier), which does not receive an upstream fix for this issue. None of these components use…
There is no upstream fix for the original, unmaintained decompress npm package used by these components (last release 4.2.1). The maintained fork, @xhmikosr/decompress, resolves this issue in versions 10.2.1 and 11.1.3, but is not used by any affected Red Hat component. As a general mitigation, only extract archives from trusted sources with the affected tooling, run extraction as a non-root user to prevent the setuid/setgid/sticky-bit issue from creating a privileged file, and verify that any symlinks or hardlinks produced by extraction resolve inside the intended output directory.Source: Red Hat security advisory for CVE-2026-53486 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | dotnet8-0-main-8.0.128-1.2.hum1 | RHSA-2026:40415 |
Frequently Asked Questions
Is CVE-2026-53486 in your dependencies?
Find it across npm, including transitive dependencies.