pnpm 11 has been released with new supply chain protections in place, making safer install behavior the default while still allowing teams to override those settings. The release sets Minimum Release Age to 24 hours by default, blocks exotic subdependencies by default, and introduces a new Allow Builds model for controlling dependency build scripts.

pnpm 11 arrived as the JavaScript, Python, and PHP ecosystems were responding to Mini Shai-Hulud, a fresh supply chain campaign that compromised packages across npm, PyPI, and Packagist. The attack used preinstall or import-time hooks to download a platform-specific Bun runtime and execute an obfuscated credential stealer targeting developer and CI/CD secrets.

pnpm 11 would not have prevented every part of this campaign but several of its new defaults are aimed squarely at the conditions that make modern package compromises move quickly: newly published malicious versions, install-time execution, and hidden or unexpected dependency sources. For JavaScript teams, this release shows how much the role of package managers has changed. They’re no longer just tools for resolving and installing dependencies, but are increasingly where supply chain security decisions get enforced.

Supply Chain Protection On by Default#

The most important security change in pnpm 11 is Minimum Release Age, which now defaults to 1440 minutes. Newly published package versions are not resolved until they are at least one day old. Teams can opt out by setting minimumReleaseAge: 0, but pnpm’s default posture now favors a built-in waiting period before fresh package releases enter installs.

Many recent package compromise campaigns depend on speed. Attackers compromise a publisher account or token, push a malicious version, and rely on automated installs, semver ranges, or fresh CI environments to pull the package before maintainers and registries can detect and remove it.

For pnpm 11 users running with the new default, those freshly published versions would not have been resolved during the first 24 hours, reducing exposure during the highest-risk window immediately after publication.

Blocking Exotic Subdeps#

pnpm 11 also turns on Block Exotic Subdeps by default through blockExoticSubdeps: true. Exotic subdependencies are transitive dependencies that resolve from non-standard sources, such as Git repositories or direct tarball URLs, rather than the normal registry resolution path. Blocking them reduces the chance that packages can quietly introduce less predictable dependency sources into the install graph.

Although this control is not a direct fix for every registry-published compromise, blocking exotic subdependencies still narrows one of the paths attackers can use to hide unexpected code in a dependency tree.

Recent supply chain campaigns rarely rely on one technique alone. They often combine compromised credentials, poisoned package releases, lifecycle scripts, external payload downloads, CI/CD secret theft, and propagation attempts. Defaults that reduce unexpected sources and delay fresh releases make those chains harder to complete.

A New Allow Builds Model#

pnpm 11 also introduces allowBuilds, a new model for controlling dependency build scripts. It replaces several older settings, including onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts. Instead of splitting build-script policy across multiple settings, teams now define a map from package name patterns to booleans.

That change is especially timely because lifecycle scripts remain one of the most abused execution paths in npm attacks.

The new Allow Builds model does not remove the need for dependency review, but it gives teams a clearer way to govern which packages are allowed to execute build scripts during installation. For organizations trying to reduce install-time execution risk, that is a meaningful simplification.

Other Highlights From pnpm 11#

Beyond the new supply chain defaults, pnpm 11 includes several notable updates:

• Native publishing and registry commands: pnpm publish, login, logout, view, deprecate, unpublish, dist-tag, and version no longer delegate to the npm CLI.
• Built-in SBOM generation: The new pnpm sbom command generates SBOMs in CycloneDX 1.7 or SPDX 2.3 JSON.
• Audit fixes through lockfile updates: pnpm audit --fix=update can fix vulnerabilities by updating packages in the lockfile instead of adding overrides. pnpm audit also now uses GHSA-based filtering instead of CVE-based filtering.
• Store v11 and faster installs: pnpm replaces the previous JSON-per-package store index with a single SQLite database and includes several install-path performance improvements.
• Isolated global installs: pnpm add -g <pkg> and pnx now use the global virtual store, giving each global install its own isolated directory, package.json, node_modules, and lockfile.
• Node.js 22 required: pnpm 11 drops support for Node.js 18, 19, 20, and 21, and pnpm itself is now pure ESM.

pnpm v12 Is Set to Introduce a Rust Installation Engine#

pnpm’s next major performance push is already visible in Pacquet, the official Rust rewrite that is expected to become pnpm’s installation engine in v12. The first phase is focused on fetching and linking, while pnpm continues to handle lockfile creation. Dependency resolution is planned for a later phase.

Recent pnpm benchmarks compare pnpm v11.0.0-rc.5 with a Pacquet-backed pnpm v12 install engine. In a warm install with both cache and lockfile present, pnpm v11 took 2.3 seconds, while the Pacquet-backed v12 path completed in 902 milliseconds. In a lockfile-only install without cache or node_modules, pnpm v11 took 4.7 seconds, compared with 3.1 seconds for the Rust-backed v12 path.

Pacquet is still under active development and not ready for production use, but the benchmark gives a clearer view of where pnpm is headed. pnpm 11 improves install performance today with Store v11 and a SQLite-backed store index. pnpm v12 is expected to go further by moving fetching and linking into a Rust implementation.