Why does package.json give a weaker answer than a lockfile?

Because it records intent, not outcome. `^1.2.3` describes a set of acceptable versions; only the lockfile records which one npm actually picked. We report range overlaps at a reduced confidence for exactly this reason - it tells you where to look, and the lockfile confirms it.

I do not have a lockfile. Is checking package.json still worth it?

Yes, and it is a good reason to start committing one. Without a lockfile, every fresh `npm install` re-resolves your ranges against whatever is on the registry that day, so your exposure changes over time even with no code change. Checking package.json shows you which ranges are currently capable of resolving to something known-bad.

Should I pin every dependency to an exact version?

Committing a lockfile is the more practical answer - it gives you reproducible installs without losing the ability to take patch updates deliberately. Pinning exact versions in package.json across a large tree tends to freeze transitive dependencies you never see, which is where most compromises actually live.

npmnpm

Check package.json for compromised dependencies

package.json declares version ranges rather than exact versions, so it answers a slightly different question: not "was I compromised" but "could this range have resolved to a compromised version". It is the right file to check when you do not have a lockfile to hand.

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

dependencies, devDependencies, peerDependencies, and optionalDependencies
semver ranges - caret, tilde, comparators, and exact pins
we skip npm aliases (npm:other@^1), plus git, file, link, and http dependencies, because they have no resolvable registry version

Probable matches

Ranges give probable exposure, not confirmed exposure. We flag a dependency when a known-compromised version satisfies your declared range - whether you actually installed it depends on when you last resolved. Check your package-lock.json to confirm.

Things worth knowing about package.json

devDependencies matter as much as dependencies

A malicious devDependency runs on every developer machine and every CI job that installs it. It does not need to reach production to steal your npm token or your cloud credentials, so we scan all four dependency blocks rather than just runtime ones.

A caret range is wider than most people expect

^1.2.3 accepts every 1.x release above 1.2.3, including one published five minutes ago by an attacker who just took over the maintainer account. That is precisely how several of the incidents in our database reached victims who had not changed a line of code.

Recent npm compromises we check for

The most recent of 107 tracked incidents affecting this ecosystem.

See all 107 incidents

package.json security questions

Why does package.json give a weaker answer than a lockfile?: Because it records intent, not outcome. ^1.2.3 describes a set of acceptable versions; only the lockfile records which one npm actually picked. We report range overlaps at a reduced confidence for exactly this reason - it tells you where to look, and the lockfile confirms it.
I do not have a lockfile. Is checking package.json still worth it?: Yes, and it is a good reason to start committing one. Without a lockfile, every fresh npm install re-resolves your ranges against whatever is on the registry that day, so your exposure changes over time even with no code change. Checking package.json shows you which ranges are currently capable of resolving to something known-bad.
Should I pin every dependency to an exact version?: Committing a lockfile is the more practical answer - it gives you reproducible installs without losing the ability to take patch updates deliberately. Pinning exact versions in package.json across a large tree tends to freeze transitive dependencies you never see, which is where most compromises actually live.

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.