How package_managers.pnpm.pnpm-missing-minimum-release-age.pnpm-minimum-release-age happens in pnpm and how to fix it

Introduction

In the site-astro project, we discovered a high severity supply chain security misconfiguration in pnpm-workspace.yaml. The workspace configuration file — responsible for governing how pnpm resolves and installs dependencies for an Astro-based website — was missing three critical security hardening settings. Most notably, the absence of minimumReleaseAge meant that any freshly published npm package version could be pulled into the project immediately, before the community had any chance to identify if it was compromised.

This matters because supply chain attacks on npm are not theoretical. The event-stream, ua-parser-js, and colors incidents demonstrated that attackers routinely publish malicious versions of popular packages. Without a quarantine period, automated dependency updates (or even manual pnpm update commands) could pull in a compromised package within minutes of its publication.

The Vulnerability Explained

What Was Missing

The original site-astro/pnpm-workspace.yaml contained only a basic configuration:

onlyBuiltDependencies:
  - esbuild
  - sharp
catalog:
  astro: ^5.16.0

This configuration tells pnpm which packages are allowed to run build scripts (esbuild and sharp) and defines a version catalog for Astro. However, it's missing three security-critical settings that pnpm v10.16.0+ supports:

1. minimumReleaseAge — No quarantine period for newly published packages
2. trustPolicy — No protection against security setting downgrades
3. blockExoticSubdeps — No blocking of unusual transitive dependencies

How This Could Be Exploited

Consider this attack scenario specific to this project:

1. An attacker identifies that site-astro depends on astro: ^5.16.0 (visible in the catalog)
2. The attacker compromises the npm credentials of a maintainer of any package in Astro's dependency tree
3. They publish a malicious patch version (e.g., bumping a transitive dependency from 1.2.3 to 1.2.4)
4. A developer on the site-astro project runs pnpm update — the malicious version is installed immediately
5. The malicious code executes during the build process (since esbuild and sharp already have build script permissions)

Without minimumReleaseAge, there's zero delay between publication and potential installation. Most supply chain attacks are detected within hours to days — a 7-day quarantine would catch the vast majority.

The Compounding Risk

The missing trustPolicy: no-downgrade setting compounds this risk. An attacker who gains partial control could potentially downgrade security settings in the lockfile, removing protections that were previously in place. The missing blockExoticSubdeps: true means transitive dependencies could introduce unusual package sources that bypass normal npm registry vetting.

The Fix

The fix adds three lines to site-astro/pnpm-workspace.yaml, inserting them between the onlyBuiltDependencies list and the catalog section:

Before

onlyBuiltDependencies:
  - esbuild
  - sharp
catalog:
  astro: ^5.16.0

After

onlyBuiltDependencies:
  - esbuild
  - sharp
trustPolicy: no-downgrade
blockExoticSubdeps: true
minimumReleaseAge: 10080
catalog:
  astro: ^5.16.0

What Each Setting Does

minimumReleaseAge: 10080 — The value 10080 is in minutes, which equals exactly 7 days. pnpm will refuse to install any package version that was published less than 7 days ago. This gives the security community time to detect and report compromised packages before they reach your project.

trustPolicy: no-downgrade — Prevents the lockfile from having its security settings downgraded. If a malicious actor modifies the lockfile (e.g., via a compromised CI pipeline or a deceptive PR), pnpm will reject changes that weaken security posture. This was added in pnpm v10.21.0.

blockExoticSubdeps: true — Blocks transitive dependencies that come from unusual sources (git repositories, tarballs, etc.) rather than the standard npm registry. This prevents attackers from sneaking in unvetted code through deep dependency chains.

Why This Is Behavior-Preserving

These settings only affect the timing and source of package installations, not functionality. Any package that has been published for more than 7 days will install normally. The project's existing dependencies (already in the lockfile) are unaffected because they were published long ago. Only new updates are subject to the quarantine.

Key Takeaways

• The site-astro/pnpm-workspace.yaml file had zero supply chain quarantine protection — any freshly published malicious package could be installed immediately during updates
• minimumReleaseAge: 10080 provides a 7-day safety net that catches the majority of supply chain attacks, which are typically detected within hours to days
• trustPolicy: no-downgrade prevents a subtle attack vector where security settings in the lockfile are weakened through seemingly innocent PRs or CI modifications
• Supply chain hardening in pnpm is a 3-line change that provides significant protection with zero impact on existing functionality
• Configuration-level security settings are often overlooked — the onlyBuiltDependencies list showed security awareness, but the newer pnpm hardening features hadn't been adopted yet

How Orbis AppSec Detected This

• Source: npm registry — newly published package versions available for installation without age verification
• Sink: pnpm-workspace.yaml at the root configuration level in site-astro/, where dependency resolution policies are defined
• Missing control: No minimumReleaseAge setting to enforce a quarantine period, no trustPolicy to prevent security downgrades, and no blockExoticSubdeps to restrict transitive dependency sources
• CWE: CWE-829 (Inclusion of Functionality from Untrusted Control Sphere)
• Fix: Added minimumReleaseAge: 10080, trustPolicy: no-downgrade, and blockExoticSubdeps: true to site-astro/pnpm-workspace.yaml

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

Supply chain attacks remain one of the most dangerous threats to modern software projects. The site-astro project's pnpm-workspace.yaml was missing critical hardening settings that pnpm provides specifically to combat these attacks. By adding minimumReleaseAge: 10080, trustPolicy: no-downgrade, and blockExoticSubdeps: true, the project now has a 7-day quarantine for new packages, protection against security setting downgrades, and blocking of exotic transitive dependencies.

If you're using pnpm v10.16.0 or later, audit your pnpm-workspace.yaml files today. These three lines of configuration provide meaningful protection against an entire class of supply chain attacks — at zero cost to your development workflow.