You can check package.json or package-lock.json for vulnerabilities online without installing anything: paste the file into a browser-based scanner and it checks the dependencies against known CVE databases. Scan the lockfile when you have it — it pins the exact installed versions, including transitive dependencies package.json never lists. A good scanner adds EPSS and CISA KEV signals, so you know which findings are real risk.
If you've ever typed "check package.json for vulnerabilities online" into a search box, you've probably landed on a single-purpose utility page, a Stack Overflow thread recommending npm audit, or a CLI tutorial that assumes you're already comfortable installing a security tool before you've even confirmed you have a problem worth solving. None of that answers the actual question: is this specific file, right now, carrying a known vulnerability? This guide shows you how to get that answer in under a minute, with no install and no signup for a quick check of up to 10 packages, using either package.json or the more accurate package-lock.json.
How to Scan package-lock.json for Vulnerabilities Online
Paste the contents of package-lock.json (or package.json if that's all you have) into a browser-based scanner and it parses the dependencies the file lists (direct and transitive when you paste the lockfile) and checks them against public vulnerability databases in seconds. No CLI and no local install, and no account for a quick check of up to 10 packages. Here's the exact flow:
- Go to /scan or the npm-specific /scanner/npm page.
- Open the Paste Text tab (there's also an Upload File tab if you'd rather drag in the file directly).
- Paste the contents of
package-lock.json— anonymous scans cover the first 10 packages; sign in free to scan larger lockfiles. If you only havepackage.json, paste that instead — see the tradeoffs below. - Click the scan button. GeekWala parses the file, reads every package and version, and queries the OSV database — which aggregates GitHub Security Advisories and ecosystem advisory databases — for known CVEs.
- Review results, ranked CISA KEV first, then EPSS above 10% (30-day exploit probability), then severity, rather than by raw CVSS alone.
The scan runs without an account, but an anonymous scan checks only the first 10 packages (and allows 3 successful scans per day per IP) — enough to try it on a small package.json. A lockfile usually lists hundreds, so create a free account (no credit card): it lifts the 10-package cap and adds scan history and project tracking (up to 200 tracked packages on the free plan), and Pro adds scheduled re-scans as new CVEs get disclosed.
How to Read Your Results: CVSS, EPSS, and KEV
A finding's CVSS score tells you how bad a vulnerability could theoretically be — remote code execution scores higher than a denial-of-service bug — but it says nothing about whether anyone is actually exploiting it. That's why raw npm audit output floods you with "critical" findings that turn out to be dormant. Two more signals fix that gap.
EPSS (Exploit Prediction Scoring System) is a FIRST.org model that estimates the probability a CVE will be exploited in the next 30 days, updated daily from real-world telemetry. A CVSS 9.8 finding with an EPSS of 0.02 is a low-urgency theoretical risk; a CVSS 6.5 with EPSS 0.85 is actively being probed right now and should jump the queue.
CISA KEV (Known Exploited Vulnerabilities) is a stronger signal still — it's a curated catalog of CVEs CISA has confirmed are being exploited in the wild, with more than 1,700 entries and growing. If a finding in your scan carries KEV status, treat it as an emergency patch regardless of what its CVSS score says. At most 6% of published CVEs are ever exploited — CVSS alone can't tell you which 6%; EPSS and KEV together can.
package.json vs package-lock.json: Which Should You Scan?
package.json declares the dependencies you chose, usually as version ranges like ^4.17.1. package-lock.json records the exact, fully-resolved tree npm actually installed — every transitive dependency pinned to one specific version. Scan the lockfile when you have it: it's the only file that reflects what's genuinely running, and most real-world CVEs live in transitive packages package.json never mentions. If you only have package.json, a scanner has to resolve ranges itself, which is less precise but still useful for a quick check. For the full mechanics of how the two files differ, see manifests vs lockfiles explained.
Automating This in CI with GitHub Actions
A one-off paste-and-scan check is useful before a release or when you inherit an unfamiliar codebase, but the same risk resurfaces every time a dependency updates. Wiring the same check into your pull request pipeline catches newly disclosed CVEs before they merge, instead of relying on someone remembering to check manually. The setup is a standard GitHub Actions workflow step that runs on every PR touching package-lock.json, fails the build on high-risk findings, and leaves routine ones for a scheduled nightly scan instead of blocking developers on every dependency bump. For the full YAML — PR gates plus a scheduled scan — see dependency scanning in GitHub Actions.
What This Scan Catches That npm audit Misses
npm audit is a solid first pass — it's free, built in, and draws on the GitHub Advisory Database. Its blind spot is prioritization: its default output gives each finding a severity label (the JSON adds a CVSS score) and nothing about exploitation, so a dormant critical and an actively-exploited moderate finding look equally urgent in the output. Layering EPSS and KEV on the same scan doesn't replace npm audit — it tells you which of its findings to actually act on this week versus which can wait for the next sprint. For npm's full landscape, from transitive-dependency depth to supply chain attacks, see the complete npm vulnerability scanning guide. Scanning a Python project instead? See how to scan requirements.txt online.
Frequently Asked Questions
Is it safe to paste package-lock.json into an online scanner?
A lockfile lists package names and pinned versions — it doesn't contain source code, secrets, or credentials, so pasting it into a reputable scanner carries minimal exposure. If your project name or internal package names are sensitive, review the file before pasting, but the dependency list itself is standard information any npm install already reveals to the npm registry.
Does this work if some of my dependencies use version ranges instead of exact pins?
Yes, but with a caveat: unpinned dependencies can't be matched to a precise vulnerable version. GeekWala flags packages using ranges and shows: "Enter exact version to enable scanning." Run npm install to generate or refresh package-lock.json first, then scan the lockfile for accurate, version-exact results.
What's the difference between scanning package.json and yarn.lock or pnpm-lock.yaml?
All three lockfile formats — package-lock.json, yarn.lock, and pnpm-lock.yaml — pin exact resolved versions and are scanned the same way at /scanner/npm. Use whichever one your project generates; the choice of package manager doesn't change which vulnerabilities exist, only which file records them.
How often should I re-scan package-lock.json?
New CVEs are disclosed daily, so a lockfile that was clean last month can carry a fresh finding today even with zero code changes. A pre-release check catches known issues before shipping; a CI gate on every pull request catches new ones the moment a dependency changes; a scheduled nightly or weekly scan catches CVEs disclosed against dependencies you haven't touched recently.
Scan your package-lock.json now → — free, no signup for up to 10 packages, results in under a minute.
