Check your package.json for vulnerabilities
Checked against OSV.dev, CISA KEV, FIRST EPSS, npm, PyPI, deps.dev, endoflife.date and Docker Hub, live.
Sample: An Express API’s package.json
A small Express API that hasn’t been updated in years. It has exact pins with known advisories, a caret range that already allows the fix, a dev-only build tool and an engines field that pins Node.js 18.
{
"name": "acme-api",
"private": true,
"engines": {
"node": "18.x"
},
"scripts": {
"start": "node server.js",
"build": "webpack"
},
"dependencies": {
"express": "4.17.1",
"body-parser": "1.19.0",
"ws": "7.4.5",
"node-fetch": "2.6.0",
"moment": "^2.29.1",
"multer": "1.4.4",
"uuid": "3.4.0"
},
"devDependencies": {
"webpack": "5.75.0"
}
}
9 findings: 5 critical, 3 warnings and 1 low priority
8 packages from package.json
Critical: 3 known vulnerabilities in ws 7.4.5
package.json7.5.11
Critical: 2 known vulnerabilities in node-fetch 2.6.0
package.json2.6.7
Critical: 11 known vulnerabilities in multer 1.4.4
package.json2.3.0
Critical: 2 known vulnerabilities in body-parser 1.19.0
package.json1.20.6
Critical: Node.js 18 is end-of-life
package.json engines24.22.0
Warning: 4 known vulnerabilities in webpack 5.75.0
package.json5.104.1Dev only
And 3 more findings in the full result.
Last checked against GitHub, OSV.dev, deps.dev, CISA KEV, FIRST EPSS, npm and endoflife.date.
What it reads in package.json
dependenciesanddevDependencies, each checked at its version. Specs that don’t name a registry version (workspace:,file:, git URLs, aliases) are skipped.engines.nodewhen it names one major, so an end-of-life Node.js shows up next to your packages.- Frameworks endoflife.date tracks, such as Next.js, React, Vue, Angular and Express, are also checked for support status.
workspaces: in a repo, the workspace folders it names are read too, and a lockfile at the root pins their versions.
Ranges, lockfiles and the version we check
package.json usually holds ranges. ^4.17.1 means any 4.x from 4.17.1 up, so the file alone doesn’t say what you installed. Without a lockfile we check the lowest version the range allows. If the range already allows the fixed version, the finding drops to low priority and says a fresh install or a lockfile update is enough, unless CISA lists the advisory as exploited.
With a lockfile we check the installed version instead. We read package-lock.json (versions 1 to 3), yarn.lock (classic and Berry), pnpm-lock.yaml and bun.lock, in the same folder or a parent folder, so a workspace package picks up the root lockfile.
Runtime, dev and indirect packages
A vulnerability in a package you ship matters more than one in a test runner. Dev dependencies rank one level lower and are tagged Dev only. Packages only the lockfile lists are tagged Indirect, and a critical advisory on one ranks as a warning, because you fix it by upgrading whatever pulls it in. Advisories CISA lists as exploited stay critical either way.
How it compares with npm audit and Dependabot
| Tool | What it reads and checks | Use it when |
|---|---|---|
| npm audit | Your whole npm install tree, sent to the npm registry’s bulk advisory endpoint. It needs a package-lock.json, and npm audit fix runs an npm install to apply fixes. | You’re in the project with npm installed and want every nested package covered. |
| Dependabot | Your GitHub repository’s dependency graph against the GitHub Advisory Database, with alerts and pull requests in GitHub. | The repo lives on GitHub and you want ongoing alerts and update pull requests. |
| This check | A pasted package.json or a public repo, no install. Adds CISA KEV and EPSS ranking, end-of-life Node.js and frameworks, deprecations and major-version drift, plus Python, Go, Rust and Docker files. | You want a ranked answer in seconds without cloning, or a task to hand to your coding agent. |
Your whole npm install tree, sent to the npm registry’s bulk advisory endpoint. It needs a package-lock.json, and npm audit fix runs an npm install to apply fixes.
Use it when: You’re in the project with npm installed and want every nested package covered.
Your GitHub repository’s dependency graph against the GitHub Advisory Database, with alerts and pull requests in GitHub.
Use it when: The repo lives on GitHub and you want ongoing alerts and update pull requests.
This check
A pasted package.json or a public repo, no install. Adds CISA KEV and EPSS ranking, end-of-life Node.js and frameworks, deprecations and major-version drift, plus Python, Go, Rust and Docker files.
Use it when: You want a ranked answer in seconds without cloning, or a task to hand to your coding agent.
Questions
Should I add package-lock.json too?
Yes, if you have one. Without it we check the lowest version each range allows; with it we check what is actually installed. Big lockfiles are trimmed in your browser to package names, versions and dev flags before anything is sent, so a 3 MB lockfile fits.
Does it check transitive dependencies?
From package-lock.json it also checks the top-level installed packages your package.json doesn’t declare, marked Indirect. From yarn.lock, pnpm-lock.yaml and bun.lock it reads the installed versions of the packages you declare. Deeply nested duplicate copies aren’t checked; npm audit covers the whole tree.
Why is a devDependency lower priority?
Dev tools usually don’t ship to production, so their advisories rank one level lower and their version drift is low priority. A devDependency with an advisory that CISA lists as exploited stays critical.
Does it check my Node.js version?
When engines.node names one major (18.x, ^20.11.0) or you add .nvmrc or .node-version, that Node.js line is checked for end of life. A minimum like >=18 is skipped: it says what your code supports, not what it runs on.
Is my package.json stored?
No. It’s read in memory to run the check. Only package names and versions are sent to the public sources, never your file.
Go further than one check
Map your repo into an architecture diagram with live health on every part, get an alert when a new critical finding lands, and hand your coding agent a brief to build from. Free to start.