Does npm audit already catch this?

`npm audit` checks your tree against the GitHub Advisory Database for *vulnerabilities* - bugs in legitimate packages. It is much weaker on *malware*: packages published deliberately to steal credentials. Those are usually removed from the registry within hours, and once the package is gone, `npm audit` frequently reports nothing at all even though the malicious version is still pinned in your lockfile and still sitting in your CI cache. That gap is what this tool covers.

Is my lockfile uploaded anywhere?

No. The parsing and matching both run in your browser as JavaScript. Your lockfile is never sent to our servers, and there is no request containing its contents. You can confirm this by opening your browser devtools network tab while you run a scan.

What should I do if it finds something?

Treat the host as compromised rather than just bumping the version. Most of these packages run code at install time, so by the time you notice, the payload has already executed with your environment variables in scope. Rotate credentials from a different machine, then pin to a safe version and clear your CI and private-registry caches - mirrors routinely keep serving tarballs after the public registry has pulled them.

My package-lock.json is huge. Will it still work?

Yes. We handle files up to 12 MB, which comfortably covers monorepo lockfiles with tens of thousands of entries. Nothing is uploaded, so size only affects how long your own browser takes - usually well under a second.

npmnpm

Check package-lock.json for compromised packages

package-lock.json is the highest-confidence file you can give us. It records the exact version npm installed for every direct and transitive dependency, so a match here is not a guess - it means the compromised version is pinned in your tree.

We check it against 2,969 compromised npm packages drawn from 107 tracked incidents. Everything runs in your browser - your package-lock.json 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 package-lock.json

lockfileVersion 1, 2, and 3 - we detect which you have and read the matching structure
the flat packages map in v2/v3, including nested node_modules/a/node_modules/b paths
the recursive dependencies tree in v1
transitive dependencies, not just your direct ones - most compromises arrive several levels deep

Confirmed matches

Because a lockfile pins exact versions, every match is confirmed rather than probable. If we flag something, that specific build really did resolve to a version named in a public advisory.

Things worth knowing about package-lock.json

Transitive dependencies are the whole point

Almost nobody installs a malicious package directly. It arrives as a dependency of a dependency, which is exactly what a lockfile captures and package.json does not. We walk the full tree and tell you the path that pulled it in.

lockfileVersion 2 contains both structures

npm 7+ writes a v2 lockfile with both the legacy dependencies tree and the modern packages map, for backwards compatibility. We read the packages map when present because it is the authoritative one, and fall back to the tree otherwise.

Recent npm compromises we check for

The most recent of 107 tracked incidents affecting this ecosystem.

See all 107 incidents

package-lock.json security questions

Does npm audit already catch this?: npm audit checks your tree against the GitHub Advisory Database for vulnerabilities - bugs in legitimate packages. It is much weaker on malware: packages published deliberately to steal credentials. Those are usually removed from the registry within hours, and once the package is gone, npm audit frequently reports nothing at all even though the malicious version is still pinned in your lockfile and still sitting in your CI cache. That gap is what this tool covers.
Is my lockfile uploaded anywhere?: No. The parsing and matching both run in your browser as JavaScript. Your lockfile is never sent to our servers, and there is no request containing its contents. You can confirm this by opening your browser devtools network tab while you run a scan.
What should I do if it finds something?: Treat the host as compromised rather than just bumping the version. Most of these packages run code at install time, so by the time you notice, the payload has already executed with your environment variables in scope. Rotate credentials from a different machine, then pin to a safe version and clear your CI and private-registry caches - mirrors routinely keep serving tarballs after the public registry has pulled them.
My package-lock.json is huge. Will it still work?: Yes. We handle files up to 12 MB, which comfortably covers monorepo lockfiles with tens of thousands of entries. Nothing is uploaded, so size only affects how long your own browser takes - usually well under a second.

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.