pnpm 11.4 is a security-heavy release aimed at a specific weak point in JavaScript supply chains: installs that look locked, but still accept changed bytes, leaked credentials, or malicious paths under the wrong conditions.
The release closes several classes of install-time risk. The biggest change is simple: if a downloaded tarball does not match the integrity value in the lockfile, pnpm now treats that as a hard failure by default. That is the behavior most teams already assume a committed lockfile gives them.
The lockfile now fails harder when bytes change#
The most important fix is around tarball integrity.
Before pnpm 11.4, when a downloaded tarball’s hash did not match the lockfile, pnpm could silently re-resolve the package from the registry and overwrite the locked integrity value. That made some broken installs recover automatically, but it also weakened the lockfile as a security boundary.
The risk is not theoretical in shape. If a registry, proxy, mirror, or republished package served different content, a clean machine could accept attacker-controlled bytes even though the project had shipped a committed lockfile. The install still looked like it was using pinned dependency metadata. The bytes were not pinned in practice.
pnpm now raises ERR_PNPM_TARBALL_INTEGRITY when the downloaded tarball does not match the lockfile. The release adds an explicit escape hatch: pnpm install --update-checksums. That flag is narrowly scoped to refreshing locked integrity values from what the registry currently serves, and pnpm prints a warning when the bypass takes effect.
That distinction matters. Updating checksums is sometimes legitimate. Doing it silently during a normal install is where the protection collapses. The new behavior forces the user or CI job to make that choice visible.
The release also states that routine refresh operations should not silently overwrite locked integrity. --fix-lockfile keeps its documented role of filling in missing lockfile entries; it is not treated as a general integrity bypass.
Missing integrity is no longer accepted for registry tarballs#
pnpm 11.4 also fails closed when registry tarball entries in the lockfile lack integrity metadata.
Previously, the worker extracting a downloaded tarball skipped hash verification if no integrity value was present. It then minted a fresh integrity value from the unverified bytes. That created a path where an attacker who could both modify the lockfile and serve altered content from the referenced tarball URL could install a tampered package without an error.
The release describes a plausible pull-request shape: strip the integrity field, rely on a modified tarball URL, and let the install process accept and bless the bytes. pnpm now rejects this at lockfile-read time with ERR_PNPM_MISSING_TARBALL_INTEGRITY.
The exception is scoped. Git-hosted tarballs and local file: tarballs are exempt because their bytes are anchored differently: by a commit SHA in a git-host URL, or by a user-controlled local path. That is a useful caveat. pnpm is not pretending every artifact type has the same trust model.
Registry credentials are now pinned to the intended registry#
The credential fix is another quiet but important change.
The issue involved unscoped per-registry settings such as auth tokens or client TLS credentials. If those values were defined in one configuration source, and a different layer later pointed pnpm at another registry, pnpm could send the credential to that later registry. In a hostile or simply misconfigured setup, that means a token intended for one registry could leak to another.
pnpm now rewrites each unscoped per-registry credential setting to a URL-scoped form at load time. It uses the registry declared in the same source, or the default npm registry if no registry is declared there. After that rewrite, a later configuration layer cannot pull the unscoped credential along to a different registry because the credential has already been pinned to the URL its author intended.
The practical form is the one teams should already prefer:
//registry.example.com/:_authToken=...
//registry.example.com/:cert=...
pnpm emits a deprecation warning when it rescopes a setting, showing where the setting was pinned and how to write it directly. The release notes that npm has rejected unscoped credentials outright for years, and pnpm intends to remove support in a future major release.
One detail is worth preserving: CA settings are intentionally not rescoped. The rationale is that they are trust anchors, not credentials, and many corporate TLS inspection setups rely on them applying globally. That is a trade-off, not a universal endorsement of MITM proxying.
Malicious lockfiles and patches lose several path tricks#
Several fixes in pnpm 11.4 are about rejecting values before lower-level tooling can interpret them dangerously.
Git resolutions now reject non-SHA references. If a git resolution’s commit field is not a 40-character hexadecimal SHA, pnpm rejects it before invoking git. The source notes a dangerous class of values on SSH or local-file transports where a malicious lockfile could smuggle command-like input into the git invocation path. The fix is strict: accept a real SHA, reject the rest.
Patch files are also constrained. Patch headers that reference paths outside the patched package directory are now rejected. Previously, a malicious patch file added in a pull request could write, delete, or rename arbitrary files reachable by the user running pnpm. In a developer workstation, that is already serious. In CI, it can become a credential or build-system problem depending on what the runner can access.
Dependency aliases get similar hardening. Aliases containing path-traversal segments, such as names shaped to escape into .git/hooks, are rejected when read from a package manifest or symlinked into node_modules. The source describes the risk as a malicious registry package using a transitive dependency key to make pnpm create symlinks at attacker-chosen paths outside the intended location.
These are not glamorous bugs. They are install-surface bugs. That is exactly why they matter: package managers sit between untrusted package metadata, developer machines, CI runners, registries, mirrors, patches, and shellable tools.
Trusted publisher metadata now needs provenance#
pnpm 11.4 changes how it treats trusted-publisher metadata. The release says that trusted publisher metadata is only treated as the strongest trust evidence when provenance is also present.
That is a sensible tightening. Publisher identity metadata is useful, but it is stronger when tied to provenance that supports how the artifact was produced. Without provenance, treating publisher metadata as the highest-confidence signal can overstate what has actually been verified.
The source does not give a long policy model here, so the safe reading is narrow: pnpm is reducing the trust weight of publisher metadata when provenance is missing. Do not turn that into a claim that all publisher metadata without provenance is useless, or that provenance by itself solves package trust.
Other fixes are operational, but still relevant#
The release includes non-security fixes and improvements that matter mainly for teams running pnpm at workspace scale or using newer runtime workflows.
One deploy-related fix addresses nested installs failing when config dependencies are involved. The release notes that the deploy directory never installs config dependencies, so the install engine they designate is not present on disk; the nested install now skips them.
pnpm also limits concurrent project manifest reads while listing large workspaces, to avoid filesystem pressure. Runtime handling gets an ERR_PNPM_BAD_RUNTIME_VERSION path for bad runtime versions. Logging was improved after pnpm auto-adds entries to the workspace configuration; the message now points users toward the documented setting that gates those updates behind a prompt, instead of referring to internal “loose mode” terminology.
These are not the headline. They do reduce ambiguity in large repositories, where unclear install behavior often becomes a security-adjacent problem simply because nobody can tell what the tool did.
What teams should do now#
Upgrade testing should focus on installs that previously “healed” themselves.
If CI starts failing with ERR_PNPM_TARBALL_INTEGRITY, treat that as a signal, not noise. Check whether the lockfile is stale, whether a registry or proxy is serving changed content, or whether a package version has been republished or mirrored inconsistently. If the change is expected, use pnpm install --update-checksums deliberately and review the lockfile diff.
Audit .npmrc and related pnpm configuration for unscoped credentials. Move tokens and client certificate settings to URL-scoped form. Do not wait for the future major release that removes the compatibility path.
Review pull requests that alter lockfiles, patch files, dependency aliases, or git resolutions with more suspicion than ordinary version bumps. pnpm 11.4 rejects several dangerous forms now, but the broader rule remains: package-manager metadata is executable influence over the install environment.
The useful reading of pnpm 11.4 is not “package installs are now safe.” They are not. The better claim is narrower and stronger: pnpm removed several places where a locked install could silently stop being locked.