Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

This will make install slower though. Are we sure it is a good default to have it on?

This will make install slower though. Are we sure it is a good default to have it on?

Security > Performance.

If a version is younger than minimum release age, it should not be installed, even if it's already in the lockfile. Better to make the installation fail.

ok, but we also have a special command for security: audit. So this could be part of pnpm audit.

Sorry for chiming in for a bit... 🙇

ok, but we also have a special command for security: audit. So this could be part of pnpm audit.

Sorry, but I'm not sure how pnpm audit helps for this issue.
I think it has been discussed extensively in #10438, but let me reiterate a little bit here.

Let's imagine situation:

1. We have minimumReleaseAge setting with 3 days config (minimumReleaseAgeStrict is true by default)
2. There's dependency A@1.0.0 in our project. It also has allowBuilds entry because it's a known dependency for us and we know it should run postinstall script
3. This dependency is compromised (happens almost weekly nowadays 🥲), hacker replaces postinstall script, releases A@1.0.1 which exfiltrates all env vars, secrets etc..
4. Maybe maliciously or maybe someone without full understanding did forced install or replaced lockfile version to use A@1.0.1 locally
5. They push it to the company repo and open PR
6. CI runs and install everything without any issues despite our minimumReleaseAge / minimumReleaseAgeStrict settings. All CI secrets are exfiltrated here...
7. This PR can be even MERGED to master => all the people who pull it and do install are pwned as well.

I'm sorry but this basically renders the whole minimumReleaseAge/minimumReleaseAgeStrict useless since they're clearly do not protect nor CI / nor other people from supply chain attack here at all.

Regarding performance tradeoff: I think we can make the check depend on minimumReleaseAgeStrict option?
If people want to choose the speed in this tradeoff - they can always set minimumReleaseAgeStrict: false or don't set minimumReleaseAge at all. I don't think it's correct to make this choice for everyone as a tool author.

This will make install slower though. Are we sure it is a good default to have it on?

If it's fast, it means it's even faster for a corrupted package to hit your machine. Nobody wants that to happen. I don't need speed, I need security.

This is what the industry should have been doing ten years ago already.

It should be the default for EVERYONE, even the beginners who still haven't received the proper security education, and who see a lot of shinny objects in the registry they want to try.

Disabling it should be INTENTIONAL

When it comes to the tradeoff between security and speed, I usually make the default behavior the secure option.

If it makes sense for the situation, I sometimes also provide an explicit optional "foot-gun mode" that users can opt into if they really want the extra speed, accepting that it may let them shoot themselves in the foot if they are not extra careful.

This will make install slower though. Are we sure it is a good default to have it on?

@ryo-manba can we have some benchmarks of this PR on a project with 10, another with 25, and a third with 50 dependencies? I'm really curious to see the real performance impact of this change.

Run pnpm install on these three projects in these scenarios:

1. Only package.json present, no node_modules or pnpm-lock.yaml
2. Only package.json and pnpm-lock.yaml present, no node_modules
3. All three package.json, pnpm-lock.yaml and node_modules present

CI runs and install everything without any issues despite our minimumReleaseAge / minimumReleaseAgeStrict settings. All CI secrets are exfiltrated here...

Regardless of this change, your CI is clearly misconfigured if your secrets can be exfiltrate at this point.

pnpm audit should be a required check in every PR. If it isn't, you can merge dependencies with vulnerabilities. So why does audit not work?

It should be the default for EVERYONE, even the beginners who still haven't received the proper security education, and who see a lot of shinny objects in the registry they want to try.

OK, well can we at least think about ways of doing it with no performance regression? Do you realize that in CI this means an additional request for every single package in the lockfile? Sometimes two requests, because the time field is not part of the abbreviated package document, so if the package is recently modified, we request the full metadata, which is much bigger in size.

can we have some benchmarks of this PR on a project with 10, another with 25, and a third with 50 dependencies? I'm really curious to see the real performance impact of this change.

These are completely unrelevant tests. 2000-3000 packages is usual for a project. I'd call that a small project.

If we are going to add this, I have the following requirements to maximize performance:

1. Have a global per-lockfile cache.

Store one record per lockfile path at <cacheDir>/minimum-release-age-verified.json:

{
  "/absolute/path/to/pnpm-lock.yaml": {
    "lockfileHash": "<sha256 of pnpm-lock.yaml>",
    "minimumReleaseAge": 1440,
    "verifiedAt": "2026-05-14T…",
    "lockfileFileSize": 154,
    "lockfileMtimeNs": "1736245123000000000",
    "lockfileInode": 12345
  }
}

On install:

• Look up the record by lockfile absolute path. If there is no record → run the gate.
• Stat the lockfile. If size, mtime, and inode all match the cached values → trust it, skip the hash entirely. Zero registry calls.
• If size differs → guaranteed miss, run the gate.
• Otherwise (size matches but mtime/inode differ — typical after a fresh CI checkout where the cache was restored) → hash the file. If the hash matches lockfileHash and current minimumReleaseAge <=
  cached minimumReleaseAge → skip the gate, and refresh the stat fields on the record so future installs hit the fast path.
• Otherwise run the gate and record the new hash + stat fields.

lockfileMtimeNs and lockfileInode are only meaningful on the same machine; CI runners reset them on every checkout. That is fine: in CI we fall back to the hash check, which is portable. The stat-cache
layer is the local-dev fast path; the hash is the source of truth.

We will recommend uploading this file as part of the CI cache.

2. Try the attestation endpoint before fetching full metadata.

When verifying dates, if there is no package document in the local cache, first try to request the attestation from the registry (e.g. https://registry.npmjs.org/-/npm/v1/attestations/pnpm@11.1.1). This
is a much smaller payload than the full metadata document, but it requires Sigstore signature verification and is only available for packages that were published with provenance — so fall back to
fetching full metadata for unattested packages.

If we will do it, might as well add other checks of the lockfile if needed.

Something to note: public benchmarks will show pnpm significantly slower in the cold-cache, up-to-date-lockfile scenario. There is no way around per-package round trips on a fresh CI runner with no
restored cache; the optimizations above target steady-state, not cold start.

One speed optimisation that can be done is fetching packages while verifying the lockfile. That means an immature package might get fetched to the store if it gets downloaded before the lockfile is completely verified. I don't know if that's ok.

Also, seems like Yarn has something like this: https://yarnpkg.com/features/security#hardened-mode

I don't know what they check. Probably the correctness of the tarball URLs. We could check that too when they are present.

Also, what to do when the lockfile gets changed? For instance, a repository is cloned and the first command is not pnpm install but pnpm add eslint. In this case should we first validate the lockfile and then make the updates? I guess we should. So almost all commands will be slower except fresh install.

@zkochan

OK, well can we at least think about ways of doing it with no performance regression? Do you realize that in CI this means an additional request for every single package in the lockfile? Sometimes two requests, because the time field is not part of the abbreviated package document, so if the package is recently modified, we request the full metadata, which is much bigger in size.

That's exactly what I implemented by myself in my CI to get security first, after I realized that pnpm was not doing it for me. We have a cult of running CI as fast as possible at any cost, which is dangerous imo.

And I'd rather depend on a community reviewed and trusted implementation rather than on my clumsy take on it.

As you mentioned, we can find ways to make it faster, which would be great, but that should never come at the expense of skipping checks we've configured in pnpm.
If the community works together on it, I'm pretty sure we can get find something.

To be honest with you, when I first took a look at the problem I was surprised that we have to fetch again the metadata for each package individually, given it's already in the lockfile and validated with a checksum, and also that the common use case is to fetch many packages at once.

I'm really not aware of all the deep technical aspects of this, so I might be overlooking some important details, and I'm not the best person to review it. So please bear with me if I'm being too naive.

But given we already have a checksum in the lockfile, having metadata cached locally is what I was expecting to see in the very first place.

So I think that the local cache makes sense.

But would that become a possible attack vector then? Injecting a poisoned cache file before resolution? Is it relevant to consider this as a threat?

Also - if an affected repository/version is deleted from npm after getting caught. It would still live in the cache file despite being removed from NPM. Is that also a possible security issue?

If we admit that we could bring changes at the repository level, which of course would be a whole other project and bigger in scope, would that help in terms of speed if, at the registry level, we were able to send a single http request to fetch the metadata of many packages at once? I opened a discussion here https://github.com/orgs/community/discussions/196051

Also, once again just throwing ideas, but would we have a way to have the date and other metadata without having to download the metadata at all, directly encoded into the source or something?

@zkochan

pnpm audit should be a required check in every PR. If it isn't, you can merge dependencies with vulnerabilities. So why does audit not work?

pnpm audit would work - the problem is that many people are not even aware of it.. They just find an outdated or poor guide online on how to get started with nodejs, how to setup a CI, they go with it and they even consider there is a risk. And what's surprising is the amount of devs who, despite having years of experience, are still not concerned with this.

The other problem is that install will run these checks on the first install - but then never again when it comes from the lockfile.
I'm paranoid when it comes to security, which led me to figure out this issue, but not immediately. So there was a period of time during which I was using pnpm thinking I was safe, and it would always run the checks when it was actually not.
Just to say that even experienced developers who are proactive about security get confused with the behavior on the install command when it comes to checking for configured checks.

But would that become a possible attack vector then? Injecting a poisoned cache file before resolution? Is it relevant to consider this as a threat?

It can, if poisoned cache will be uploaded from a fork repository. See the recent tanstack attack.

I am not saying local cache will not be used during lockfile verification but even reading 2K metadata files from cache will make install slower. Hence, the idea of caching the lockfile verification result is a good call today.

@coderabbitai review

Thanks for merging this and for the cache-poisoning explanation, that fixed the main concern. One thing I'd still like to understand: the perf cost on which you originally pushed back.

Is there a follow-up planned?

Thank you for your time

@zkochan Happy to see this merged! I'm glad we agreed here and moving this forward, than you! 🙏

I'm sorry for the late reply but I wanted to comment on a couple of things, feel free to ignore if you don't have time for this, it doesn't matter much I'm just curious on your perspective.

Regardless of this change, your CI is clearly misconfigured if your secrets can be exfiltrate at this point.

That's a bit too strong statement, you mean that pnpm install should always happen only in complete isolation of any secrets or only with (ignore-scripts)? In an ideal world in a vacuum probably yeah of course.
But real CIs routinely have install-time access to NPM_TOKEN, GitHub tokens, AWS creds, registry creds, etc. Sandboxing every install script is not the default and breaks many legitimate packages (native builds, etc.). Recent npm worm incidents (shai-hulud, etc.) succeeded precisely because that hardening is rare in practice.
So with all respect but being that dismissive is a bit irresponsible.

Maybe misunderstood something, so please clarify if you have time, I'm really curious about this point.

pnpm audit should be a required check in every PR. If it isn't, you can merge dependencies with vulnerabilities. So why does audit not work?

In my career I've never seen npm/pnpm audit being used as a required check for every PR on CI.
I think it would be a bit too much, since sometimes you can't upgrade dependencies right away (especially for big projects), sometimes the severity is incorrect as well and you don't want to block all PRs on that.
Usually it's a separate process completely and actually I feel like Dependabot/Renovate are much more popular tools for that than audit commands.

@ryo-manba Thanks a lot for working on this :).

@Lisenish Regarding pnpm audit, you can use flags:

• --audit-level to fail only on, say, critical vulnerabilities,
• --ignore <vulnerability> to skip a vulnarability if you dont have time to fix it and you flagged it as safe to ship

Regarding the tone of his comment, I dont think you should feel affected. Alas, that's how is open source today. Ton of people pinging you for all and everything, and even the most respectful maintainer will end up sounding dismissive because of the need to deal with volume of issues efficiently.

@gsouf Thank you for the reply :)

Regarding pnpm audit, you can use flags

Yeah thanks, the discussion was that pnpm audit already prevents this type of attacks: so if we'd use this parameters it kind defeats the purpose, since it means that we might sneak in vulnerable dependency.
Plus, these types of vulnerabilities detected fast but not immediately (that's why we need minimumReleaseAge parameter).
Moreover it would mean I need to have dependency of all CI jobs with pnpm install on the job with pnpm audit to make sure they're not executed before we confirm there's no vulnerabilities.

Overall I don't think pnpm audit is a good solution for that (while I agree it could work) and happy we agreed to merge PR.
Wether it should be run on CI as required check, or you can use Dependabot/etc - I think it's a matter of preference and could be controversial topic, so the tool itself shouldn't make assumptions about that.

Just incase, it's also not specifically about my or my companies CIs, it has --ignore-scripts setting in install already actually, so the scenario I described above sholdn't be a problem for us (at least while it works for us with this parameter 😄).

BTW, I checked now and it seems it's not required check for pnpm itself also (I think this confirms my point that I never saw it actually being a required one)

Regarding the tone of his comment

Yeah I know, I didn't meant the tone actually, I'm not that sensitive haha :). I meant that if you're maintainer of such a big and important tool as pnpm, you can't just dismiss security suggestions with "you just misconfigured your CI!", you must think about security in depth.

Since PR is merged, it;s good already I just curious what is the proper CI setup from the @/zkochan viewpoint, maybe I could learn something.

is kinda not ideal when migrating from v10 to v11:

✗ Lockfile failed supply-chain policy check (554 entries in 1.7s)
[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 36 lockfile entries failed verification:
  @typescript-eslint/eslint-plugin@8.59.4 was published at 2026-05-18T17:43:41.000Z, within the minimumReleaseAge cutoff (2026-05-18T12:09:22.863Z)
  @typescript-eslint/parser@8.59.4 was published at 2026-05-18T17:43:20.000Z, within the minimumReleaseAge cutoff (2026-05-18T12:09:22.863Z)
  @typescript-eslint/project-servic