GHSA-mp2f-45pm-3cg9 is a critical-severity (CVSS 9.1) Path Traversal vulnerability in @xhmikosr/decompress. O3 Security confirms whether GHSA-mp2f-45pm-3cg9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Decompress: Archive extraction can create files and links outside of 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 GHSA-mp2f-45pm-3cg9.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-mp2f-45pm-3cg9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 366,848 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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.1 |
| 📦npm | @xhmikosr/decompress | ≥ 11.0.0&&< 11.1.3 | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @xhmikosr/decompress to 10.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mp2f-45pm-3cg9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mp2f-45pm-3cg9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mp2f-45pm-3cg9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
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…
Frequently Asked Questions
Is GHSA-mp2f-45pm-3cg9 in your dependencies?
O3 detects GHSA-mp2f-45pm-3cg9 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.