Which pnpm lockfile versions are supported?

v6 and v9, which between them cover pnpm 8 and 9 onwards. The two use noticeably different key shapes, so we detect the layout and read whichever applies rather than assuming one.

Do I need to scan every workspace in my monorepo?

No. The root pnpm-lock.yaml already contains the resolved graph for all workspace packages, so one paste covers everything.

Does pnpm’s stricter node_modules layout prevent supply-chain attacks?

It prevents *phantom dependencies* - code importing packages it never declared. That is a genuine robustness win, but it does nothing about a package you did declare being compromised, or a transitive dependency of it being compromised. That is what this checks.

pnpmnpm

Check pnpm-lock.yaml for compromised packages

pnpm-lock.yaml pins the exact version of every package in your store, including the full transitive graph, so it gives a confirmed answer. We support both the v6 and v9 lockfile layouts.

We check it against 4,521 compromised npm packages drawn from 165 tracked incidents. Everything runs in your browser - your pnpm-lock.yaml never leaves your machine.

By ticking this box, I confirm I have read and agree to the Terms & Conditions.

Parsed locally in your browser. Nothing leaves your device, no logging, no network round-trip.

What we read from your pnpm-lock.yaml

v6 layout - a single packages map with /name/version keys
v9 layout - split packages and snapshots maps with name@version keys
importers, so we can tell your direct dependencies apart from transitive ones
peer-resolution suffixes such as name@1.2.3(react@18.3.1), which we strip back to the real version

Confirmed matches

pnpm lockfiles pin exact resolved versions, so every match is confirmed rather than probable.

Things worth knowing about pnpm-lock.yaml

Workspaces are covered

In a pnpm monorepo the root lockfile carries every workspace package under importers. Pasting the single root pnpm-lock.yaml therefore checks the whole repo at once - you do not need to scan each package separately.

The content-addressable store does not protect you

pnpm’s store deduplicates by content hash, which is excellent for disk usage but has no bearing on whether the content is malicious. A compromised version hashes and stores exactly like a clean one.

Recent npm compromises we check for

The most recent of 165 tracked incidents affecting this ecosystem.

See all 165 incidents

pnpm-lock.yaml security questions

Which pnpm lockfile versions are supported?: v6 and v9, which between them cover pnpm 8 and 9 onwards. The two use noticeably different key shapes, so we detect the layout and read whichever applies rather than assuming one.
Do I need to scan every workspace in my monorepo?: No. The root pnpm-lock.yaml already contains the resolved graph for all workspace packages, so one paste covers everything.
Does pnpm’s stricter node_modules layout prevent supply-chain attacks?: It prevents phantom dependencies - code importing packages it never declared. That is a genuine robustness win, but it does nothing about a package you did declare being compromised, or a transitive dependency of it being compromised. That is what this checks.

Check another file

We only list package versions named by the original advisory - we don't infer compromises. Spotted one we're missing? Send it in.