Does this work with Yarn Plug’n’Play?

Yes. PnP changes how modules are *resolved at runtime*, not how the lockfile records versions. Your yarn.lock still lists resolved versions and we read it the same way.

Does `yarn audit` do the same thing?

Not quite. `yarn audit` queries an advisory database for known vulnerabilities in legitimate packages. Deliberately malicious packages get pulled from the registry quickly, and after that the advisory lookup often comes back clean even though the bad version is still pinned in your lockfile. We match against the malicious versions themselves, so takedown does not hide them.

Is my yarn.lock sent to a server?

No. Parsing and matching happen in your browser. Nothing containing your lockfile leaves the machine.

Yarnnpm

Check yarn.lock for compromised packages

yarn.lock records the exact version Yarn resolved for every dependency in your tree, so a match is confirmed rather than probable. We read both Yarn Classic (v1) and Yarn Berry lockfiles.

We check it against 4,521 compromised npm packages drawn from 165 tracked incidents. Everything runs in your browser - your yarn.lock 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 yarn.lock

Yarn Classic (v1) entries - "pkg@^1.0.0": followed by a version field
Yarn Berry entries, including the __metadata block, which we skip
multi-specifier keys, where several ranges share one resolved entry
scoped packages, resolved back to their real @scope/name

Confirmed matches

Because yarn.lock pins resolved versions, every match is confirmed. If we flag something, that version really is what Yarn installed.

Things worth knowing about yarn.lock

Berry and Classic are both handled

The two formats differ enough to break naive parsers, so we use Yarn's own syntax parser rather than a regex. You do not need to tell us which one you have - paste it and we detect it.

One resolution, many requesters

Yarn deduplicates, so a single entry often satisfies several different ranges requested by different parts of your tree. We dedupe on name and version so a widely-shared compromised package is reported once rather than a dozen times.

Recent npm compromises we check for

The most recent of 165 tracked incidents affecting this ecosystem.

See all 165 incidents

yarn.lock security questions

Does this work with Yarn Plug’n’Play?: Yes. PnP changes how modules are resolved at runtime, not how the lockfile records versions. Your yarn.lock still lists resolved versions and we read it the same way.
Does `yarn audit` do the same thing?: Not quite. yarn audit queries an advisory database for known vulnerabilities in legitimate packages. Deliberately malicious packages get pulled from the registry quickly, and after that the advisory lookup often comes back clean even though the bad version is still pinned in your lockfile. We match against the malicious versions themselves, so takedown does not hide them.
Is my yarn.lock sent to a server?: No. Parsing and matching happen in your browser. Nothing containing your lockfile leaves the machine.

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.