GHSA-54hh-g5mx-jqcp
MEDIUMGHSA-54hh-g5mx-jqcp is a medium-severity (CVSS 6.8) CWE-345 vulnerability in pnpm. O3 Security confirms whether GHSA-54hh-g5mx-jqcp is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
pnpm: Unsafe default behavior breaks integrity check
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-54hh-g5mx-jqcp.
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-54hh-g5mx-jqcp 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 0 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.
pnpmnpmDescription
While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.
Summary
pnpm install in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml.
When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully.
This means the lockfile integrity check does not act as a hard stop by default.
Reproduction Scenario
- Run a local npm-compatible registry.
- Publish or serve
[email protected]with tarball contentv1. - Install it with pnpm:
pnpm add [email protected] --registry=http://127.0.0.1:48741
- Confirm
pnpm-lock.yamlcontains thev1integrity:
packages:
[email protected]:
resolution:
integrity: sha512-...v1...
- Change the registry metadata and tarball for the same
[email protected]to contentv2. - On a clean store/cache, run:
pnpm install --registry=http://127.0.0.1:48741
Observed Behavior
pnpm detects the checksum mismatch:
WARN Got unexpected checksum for "http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz".
Wanted "sha512-...v1..."
Got "sha512-...v2...".
ERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.
However, the install still succeeds:
INSTALL_RC=0
INSTALLED=v2-replaced
The lockfile is then rewritten to trust the new remote integrity:
packages:
[email protected]:
resolution:
integrity: sha512-...v2...
Expected Behavior
If a downloaded tarball does not match the integrity recorded in pnpm-lock.yaml, the install should fail by default.
The lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.
Security Impact
This behavior weakens the protection normally expected from a committed lockfile.
If a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker's replacement package even though the project already has a lockfile with the original integrity.
Examples of affected new or clean environments include:
- an engineer setting up the project on a new machine
- a new team member onboarding to the project
In this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in pnpm-lock.yaml. However, instead of failing by default, plain pnpm install performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.
In other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.
This is especially relevant for:
- private registries that allow overwriting or republishing the same version
- registry mirrors or proxies that can serve changed metadata and tarballs
- compromised public or private registries
- compromised registry proxy infrastructure
The behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.
This issue does not occur when --frozen-lockfile is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.
However, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.
For that reason, it may be safer for pnpm's default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.
Comparison
In the same scenario, npm install with an existing package-lock.json fails with EINTEGRITY and does not install the changed tarball.
pnpm install --frozen-lockfile also fails as expected:
ERR_PNPM_TARBALL_INTEGRITY
The issue is specific to the default non-frozen behavior of plain pnpm install in non-CI environment.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | pnpm | all versions | 10.34.0 |
| 📦npm | pnpm | ≥ 11.0.0&&< 11.4.0 | 11.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pnpm. 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 pnpm to 10.34.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-54hh-g5mx-jqcp 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-54hh-g5mx-jqcp 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-54hh-g5mx-jqcp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-54hh-g5mx-jqcp in your dependencies?
O3 detects GHSA-54hh-g5mx-jqcp across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.