NPM Lockfile Threat Scanner – Compromised Package Checker

Is your project affected by the latest npm supply-chain attack? Paste a package-lock.json, yarn.lock or pnpm-lock.yaml (or point at a URL) and get an answer in seconds. The scanner checks every package version in your lockfile against the OSV.dev malicious-package feed (the OpenSSF malicious-packages database, MAL-* advisories) — the same data that flagged the 2026 axios, node-ipc and Red Hat "Miasma" compromises on the day they happened.

No CLI to install, no repo to clone, no signup with a security vendor. Works from a browser, from CI via the API, or as an MCP tool your AI agent can call.

What it detects

Known-malicious package versions — account takeovers, trojanized releases, credential stealers, worms — as catalogued by OSV/OpenSSF. This is triage for incidents like:

• Axios takeover (March 2026) — versions 1.14.1 / 0.30.4 shipping a cross-platform RAT via a phantom plain-crypto-js dependency
• node-ipc (May 2026) — three versions with an embedded credential stealer
• Red Hat "Miasma" (June 2026) — ~32 @redhat-cloud-services packages published with valid SLSA provenance
• Shai-Hulud worm & chalk/debug takeover (2025)

For the major incidents above, findings are enriched with hand-curated incident context: what the payload does, what else to hunt for (exfiltration endpoints, dropped files, rogue repos), and links to the primary vendor write-ups — the stuff a terse advisory doesn't tell you at 11pm during an incident.

This scanner focuses on malicious code, not ordinary CVEs. For general vulnerability audits use npm audit or OSV-Scanner; use this when you need a fast "are we hit?" answer.

How to check a lockfile for malicious packages

1. Paste your lockfile into Lockfile content (or add raw URLs under Lockfile URLs — GitHub blob links are accepted).
2. Run. A 2,000-dependency lockfile typically finishes in a few seconds.
3. Read the verdict:
   • CLEAN — no known-malicious versions matched.
   • COMPROMISED-PACKAGES-FOUND — the dataset lists each hit with the advisory, incident context, hunting guidance and a remediation recommendation.

You can also skip the lockfile and check specific packages via the Package list input (axios@1.14.1, one per line) — handy when a new advisory drops and you just want to check the names from the headline.

Supported lockfile formats

• package-lock.json / npm-shrinkwrap.json (npm, lockfile versions 1–3)
• yarn.lock (Yarn 1 classic and Yarn 2+ Berry)
• pnpm-lock.yaml (v5, v6 and v9 formats)

Run it from CI or scripts

Call the Actor via the Apify API on every dependency update PR, or on a schedule. A non-empty findings array (or verdict != "CLEAN" in the OUTPUT record) is your signal to fail the build. Pair it with an Apify schedule + webhook to get standing daily checks of your dependency list — new advisories are matched as soon as OSV publishes them.

Privacy: what happens to my lockfile?

Lockfiles are mostly public data (package names, versions, registry URLs), but they can reveal internal package names — exactly the intelligence a dependency-confusion attacker wants — and private registry hostnames.

• Skip private/internal packages is ON by default: any package that resolved from a private registry, git, file: or workspace: source is counted and listed as skipped, but its name is never sent to the external OSV API.
• Your lockfile is processed inside your own Apify account. This Actor does not copy, retain or share your input; results live in your run's dataset and key-value store under your account's standard retention.
• Only name@version pairs of publicly-resolved packages are sent to OSV.dev for matching.

Note: Yarn Berry lockfiles don't record registry URLs, so private-registry detection there is limited to non-npm: protocols — redact internal entries yourself if that matters for you.

Disclaimer

This tool matches your dependencies against known, publicly catalogued malicious package versions. A CLEAN verdict is not a guarantee of safety — it means no match in the OSV.dev feed at scan time. Zero-day compromises, not-yet-catalogued packages and non-npm attack vectors are out of scope. Findings and remediation guidance are provided as-is, without warranty; validate against the linked advisories before taking destructive action. You are responsible for the files you submit and for your own incident response.

Output example

{
  "verdict": "MALICIOUS",
  "package": "axios",
  "version": "1.14.1",
  "advisories": [{ "id": "MAL-2026-2307", "summary": "Malicious code in axios (npm)", "published": "2026-03-31" }],
  "incident": {
    "name": "Axios maintainer account takeover (March 2026)",
    "payload": "Hijacked lead-maintainer npm account published axios 1.14.1 and 0.30.4 carrying a phantom dependency, plain-crypto-js@4.2.1...",
    "huntFor": ["plain-crypto-js anywhere in lockfiles — it has no legitimate use", "..."]
  },
  "recommendation": "Remove or pin away from axios@1.14.1 immediately, rebuild the lockfile, and rotate credentials..."
}

The full scan summary (verdict, counts, skipped private packages, parse errors) is stored as the run's OUTPUT key-value record.

FAQ

How fresh is the data? OSV.dev ingests the OpenSSF malicious-packages database continuously; for every major 2026 incident the malicious versions were catalogued the same day the attack was disclosed. Each scan queries OSV live — there is no stale local mirror.

Does it find ordinary CVEs (vulnerabilities)? No — by design it reports only malicious code advisories (MAL-*), so the signal is "you are compromised", never "you should upgrade sometime". That's what makes it usable as a CI gate.

Will it flag my internal/private packages? With the default settings it never even transmits their names. See the Privacy section.

What does it cost? Pricing is pay-per-event: a flat fee per package version checked. A typical application lockfile (1,000–3,000 unique packages) costs a few cents per scan.