pnpm 11 RC Makes a 24-Hour Release Delay the Default, Turning a Supply-Chain Workaround Into a Baseline

Overview

The JavaScript package manager pnpm published the release candidate for version 11 on April 21, 2026, and the headline change is not a performance chart. It is a set of defaults that treat every freshly published package as suspect until it has aged for at least 24 hours. According to InfoQ, pnpm 11 ships with minimumReleaseAge set to 1 day out of the box, blockExoticSubdeps enabled by default, and strictDepBuilds also true by default — a configuration posture that would have blunted several of the supply-chain compromises that battered the ecosystem this spring.

The timing is pointed. In the twelve days before the RC landed, maintainers across the Node ecosystem were still cleaning up after a run of attacks that, as The Register reported, turned the vulnerability scanner Trivy and the ubiquitous HTTP client axios into short-lived malware delivery vehicles. pnpm 11’s defaults translate the post-incident advice — wait a day before pulling new versions, keep SBOMs, gate build scripts — into behavior that applies whether or not an individual developer opts in.

What Changed in pnpm 11 RC

The RC notes published by InfoQ describe a larger release than the security flags alone suggest. pnpm is now distributed as pure ESM, drops support for Node.js versions 18 through 21, and requires Node.js v22 or later. The on-disk store has been rebuilt around an SQLite-backed index, with direct-to-store writes that eliminate the older staging directory, pre-allocated tarball downloads, and NDJSON metadata caching. The HTTP layer moves to Undici with Happy Eyeballs.

The configuration surface has also been trimmed and consolidated. InfoQ notes that pnpm 11 stops reading configuration from the "pnpm" field in package.json and from npm_config_ environment variables, pulling settings into pnpm-workspace.yaml instead. The global configuration file has moved to YAML, and the older trio of onlyBuiltDependencies, neverBuiltDependencies, and ignoredBuiltDependencies has been replaced by a single allowBuilds map — pattern keys mapped to booleans — so build-script policy lives in one place.

Three security-relevant defaults are the ones that reshape day-to-day behavior:

• minimumReleaseAge = 1 day. According to InfoQ, newly published versions are not resolved for 24 hours, which pnpm frames as giving “the community time to detect and remove compromised versions.”
• blockExoticSubdeps = true. Transitive dependencies that try to pull from git repositories or tarball URLs are blocked unless explicitly permitted.
• strictDepBuilds = true. Postinstall and other build scripts from unreviewed dependencies fail installation rather than silently executing.

The RC also introduces a set of new subcommands — pnpm ci, pnpm sbom, pnpm clean, pnpm peers check, and pnpm runtime set — along with isolated global installs, where each global package receives its own directory, package.json, node_modules, and lockfile, per InfoQ.

Why a 24-Hour Gate Matters Now

The case for aging packages before resolving them is no longer theoretical. On March 31, 2026, attackers linked by Google’s Threat Intelligence Group to the North Korean cluster UNC1069 hijacked a maintainer account on axios — a library with roughly 100 million weekly downloads — and published two booby-trapped releases, axios@1.14.1 and axios@0.30.4. According to The Register, the attackers bypassed the project’s GitHub Actions CI/CD pipeline by taking over the maintainer’s npm account and changing its associated email, then published manually via the npm CLI. The malicious versions smuggled in a fraudulent dependency named plain-crypto-js@4.2.1 that carried platform-specific payloads: a macOS daemon, a Windows PowerShell variant, and a Linux Python backdoor.

The window of exposure is the important number. The Register reports that the two affected axios versions were published 39 minutes apart after the malicious dependency had been staged 18 hours earlier, and that the packages were yanked before widespread adoption — though some developers and CI pipelines had already pulled them. A default one-day delay in package resolution would have expired the window for most consumers before the bad versions ever left the registry.

That is more or less the view that security researchers pushed in the aftermath. In The Register’s April 11 analysis of the axios and Trivy incidents, Wiz’s Ben Read put it plainly: “If you create a rule in your development environments where you don’t download any versions newer than 24 hours, you would have skipped these.” Cisco Talos’s Nick Biasini, quoted in the same piece, emphasized software bills of materials: “The biggest thing that you can do is understand where your risk is…make sure that you have those SBOMs, understand where these packages are.” pnpm 11’s new pnpm sbom command sits squarely in that recommendation, and the minimumReleaseAge default operationalizes Read’s rule for everyone who upgrades.

This builds on prior coverage by The Machine Herald of the axios compromise, which detailed how the attackers moved, and on earlier reporting on the PackageGate disclosures that revealed how git dependencies could bypass post-Shai-Hulud install defenses — exactly the class of vector that blockExoticSubdeps now shuts by default.

What the Defaults Cost Developers

Security defaults are a negotiation with developer ergonomics, and pnpm 11’s choices will surface friction. A 24-hour minimumReleaseAge means a team that publishes a fix to an internal package cannot pull it into dependent projects through pnpm’s normal resolution for a full day — a constraint that projects with active internal release cadences will need to plan around. pnpm exposes escape hatches such as minimumReleaseAgeExclude for internal packages, and the documentation referenced by InfoQ also describes a minimumReleaseAgeIgnoreMissingTime flag that skips the check when registry metadata lacks a time field, but those still require explicit configuration.

blockExoticSubdeps will also break installs for projects that, perhaps unknowingly, pull a transitive dependency from a git URL or tarball. In practice that surfaces hidden edges in the dependency graph — which is partly the point — but it is also the kind of change that produces Monday-morning support tickets. strictDepBuilds has a similar shape: it replaces silent postinstall execution with an installation error until maintainers are explicitly listed in allowBuilds. Per InfoQ, the single allowBuilds map is intended to make those decisions auditable in one place rather than scattered across legacy settings.

The breaking changes that accompany these defaults raise the upgrade bar. Dropping Node.js 18 through 21, moving to ESM-only distribution, migrating global configuration to YAML, and ignoring package.json’s "pnpm" field together mean pnpm 11 is not a drop-in replacement for pnpm 10.

What We Don’t Know

The RC is not the final release. InfoQ documents the defaults and breaking changes as of the RC, but the final shipping behavior — including any softened defaults in response to community feedback — is still subject to change. pnpm’s public roadmap discussion, referenced in the coverage, does not commit to a specific GA date.

It is also unclear how quickly the wider ecosystem will follow. npm itself has moved on other fronts — trusted publishing with OIDC became generally available in 2025 and bulk configuration landed in February 2026, per GitHub’s changelog — but neither npm nor Yarn has announced a matching default-on 24-hour resolution delay. Whether pnpm’s choice becomes an ecosystem norm or remains a differentiator will depend on how it holds up in practice once the RC reaches GA and large monorepos start upgrading.

What the RC does establish is a clearer precedent. After a spring in which, The Register noted, attackers compressed the detection window on widely used packages to hours, a package manager that refuses to pull any version newer than a day old is a bet that rapid detection — Wiz reported under-12-hour windows on the axios incident — is now fast enough for the defaults to catch most of what matters.