Evidence used
- No CISA KEV confirmation is currently recorded.
- A structured source references public exploit or proof-of-concept material.
- EPSS is 0.98% for the current model date.
BlackTreeCVE Intelligencepnpm · pnpm
Official source article: GitHub GHSA-VM32-9RQF-RH3R ↗. Check the applicable product and release in the original source.
Medium technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
These OSV and GitHub advisory ranges apply only to the named package and ecosystem. A listed fixed version is not a universal product patch or proof that an update is installed.
| Ecosystem and package | Affected range | First fixed version | Evidence |
|---|---|---|---|
| npmpnpm | < 9.15.0 | 9.15.0 | GitHub advisory ↗upstream repository advisory · 10 Dec 2024 |
| npmpnpm | SEMVER: introduced 0; fixed 9.15.0 | 9.15.0 | OSV record ↗aggregator derived · 10 Sep 2026 |
Medium technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
Patch availableThe package manager pnpm prior to version 9.15.0 seems to mishandle overrides and global cache: Overrides from one workspace leak into npm metadata saved in global cache; npm metadata from global cache affects other workspaces; and installs by default don't revalidate the data (including on first lockfile generation). This can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B. Users generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it). Here, that expectation is broken. Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs. Version 9.15.0 fixes the issue. As a work-around, use separate cache and store dirs in each workspace.
The package manager pnpm prior to version 9.15.0 seems to mishandle overrides and global cache: Overrides from one workspace leak into npm metadata saved in global cache; npm metadata from global cache affects other workspaces; and installs by default don't revalidate the data (including on first lockfile generation). This can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B. Users generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it). Here, that expectation is broken. Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs. Version 9.15.0 fixes the issue. As a work-around, use separate cache and store dirs in each workspace.
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
An attacker operating through a network path may attempt exploitation when the stated preconditions are met. If successful, the issue may execute code or commands in the affected security context.
The package manager pnpm prior to version 9.15.0 seems to mishandle overrides and global cache: Overrides from one workspace leak into npm metadata saved in global cache; npm metadata from global cache affects other workspaces; and installs by default don't revalidate the data (including on first lockfile generation). This can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B. Users generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it). Here, that expectation is broken. Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs. Version 9.15.0 fixes the issue. As a work-around, use separate cache and store dirs in each workspace.
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
An attacker operating through a network path may attempt exploitation when the stated preconditions are met. If successful, the issue may execute code or commands in the affected security context.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
A structured CVE source labels at least one public reference as exploit material. BlackTree has not independently validated that it is safe, reliable or weaponised.
CWE-426: Untrusted Search Path. The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:H/SI:H/SA:HCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 10 Dec 2024 · Last source change 31 Dec 2025, 01:11 UTC · CWE-426 · Untrusted Search Path
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.