CVE-2025-69264 is a high severity flaw (CVSS 8.8) in pnpm. Versions 10.0.0 through 10.25 let git hosted dependencies run prepare, prepublish and prepack scripts during install, bypassing the default block on lifecycle scripts. Upgrade pnpm to 10.26.0 or later, and review any git dependencies.
What's affected
- pnpm 10.0.0 through 10.25.
- Fixed version: 10.26.0.
- Affects installs that fetch dependencies hosted in git repositories.
How to check if you're exposed
Check the pnpm version on developer machines and in CI:
pnpm --version
Then look for git hosted dependencies. Search package.json and pnpm-lock.yaml for entries that point at a git URL, a github: shorthand or a commit hash instead of a registry version. If you have none, the described path is not triggered by your own manifests, but transitive dependencies can contain them too, so check the lockfile.
You can also paste a manifest or lockfile into the free in-browser dependency scan at gold.safeguard.sh/scan. It lists known CVEs for the versions it finds and runs in your browser.
What to do now
- Upgrade pnpm to 10.26.0 or later everywhere: laptops, CI images and Docker builds. If you pin it through the packageManager field in package.json, update that pin.
- Review the lockfile for git hosted dependencies and replace them with registry releases where possible.
- Pin any remaining git dependency to a full commit hash from a source you trust.
- Run installs in CI with no secrets in the environment and with limited network access.
- Keep onlyBuiltDependencies short and reviewed, since it is the allow list pnpm 10 uses for build scripts.
Why it matters
The record maps this to CWE-693, protection mechanism failure. pnpm 10 turned off dependency lifecycle scripts by default, a sensible control after years of install time malware in package registries. The gap was that git hosted packages must be prepared before they can be used, and the scripts involved in that step were not covered by the block.
The effect is that a dependency fetched from a git repository could run code on the machine doing the install, with no approval. That machine is often a CI runner holding tokens and deploy keys, or a developer laptop. The vector needs user interaction, which here means running the install.
The lesson reaches beyond pnpm: a control is only as good as the list of places it applies. An inventory of what your builds actually fetch, including from git, shows where this kind of gap would bite. The record does not list this CVE as exploited in the wild.
Install scripts are a long running source of supply chain incidents, which is why pnpm 10 turned them off by default. This CVE is a reminder that git hosted dependencies are a separate path with their own rules. A registry package is built and published by its maintainer, while a git dependency is built on your machine, from whatever the repository holds at that moment.
If you need a git dependency, pin it to a full commit hash and review the repository's scripts before adding it. Prefer a published release. Keep CI installs separate from deploy steps, so that the job that fetches packages does not also hold production credentials.
Inventory is the first step. Searching one lockfile is easy. Searching every repository in the company is the job that tooling should do, which is what a dependency inventory is for.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does CVE-2025-69264 affect registry only projects?
The advisory describes git hosted dependencies. Check the lockfile for them, including transitive ones, and upgrade pnpm regardless.
Sources
- https://github.com/pnpm/pnpm/security/advisories/GHSA-379q-355j-w6rj
- https://access.redhat.com/security/cve/CVE-2025-69264
Last reviewed: 19 October 2026.
