About the Dependency CVE Checker
Most side projects are quietly vulnerable, and almost nobody finds out, because the tools that tell you normally want a repository integration, a paid seat, or at minimum a full npm install. This one wants a paste. Drop in a package.json, requirements.txt or composer.json and it reads every pinned version, matches each one against the vulnerability ranges in the advisory databases, and tells you which are affected right now.
Version matching runs against OSV.dev, Google’s open vulnerability aggregator, which carries the GitHub Advisory Database, PyPA and Packagist feeds and — critically — knows the exact version ranges each advisory affects rather than just a package name. Every finding shows its CVE identifier, severity, CVSS v3 score computed from the published vector, the CWE weakness class, and the version that fixes it. Opening a finding pulls NIST’s own NVD record for the full description and references.
Your manifest is parsed in your browser; only package names and versions are sent to the lookup, never file contents, comments or private registry URLs. Results are cached for twelve hours. Pair it with the HTTP Security Grader for what your server exposes and the SSL Certificate Monitor for what your TLS layer is doing.
Pick any finding above to decode its vector into plain English — how the flaw is reached, what it takes to exploit, and what it costs you.
A written summary you can hand to a client or attach to a ticket — findings, severity, fix versions and a plain-English risk statement.
How to Use the Dependency CVE Checker
Paste the whole manifest file — you do not need to strip anything out. The format is
detected from the content, so a package.json, a requirements.txt and a
composer.json all just work. The parser reads every dependency block it finds,
including devDependencies and require-dev, and shows you the count
before you scan so you can see nothing was missed. Then hit scan: every package and version pair
is matched in parallel against vulnerability ranges, and results come back in a couple of seconds.
For the most accurate picture, paste the resolved versions rather than the ranges
in your manifest. A caret range like ^4.17.4 is checked as 4.17.4, which is the
worst case your range permits — correct and conservative, but your lockfile may already have
resolved to a patched 4.17.21.
Where This Data Comes From, and Why Ranges Matter
Matching a package name against a vulnerability list is easy and nearly useless — it flags
every version of lodash that ever existed. What matters is the
affected version range: this advisory hits everything below 4.17.12, that one
everything from 2.0.0 up to but excluding 2.4.1. This tool resolves against
OSV.dev, which normalises the GitHub Advisory Database, the PyPA advisory
database and Packagist’s feed into machine-readable ranges with proper semver and PEP 440
semantics. Opening a finding then pulls the record from NIST’s NVD for the
canonical description, the assigning authority’s notes and the reference links — the
two sources answer different questions and this tool uses each for what it is good at.
Reading a CVSS Score Without Panicking
Every score here is computed from the published CVSS v3 vector using the official formula, so it matches what NVD shows. The bands are fixed: 9.0–10.0 critical, 7.0–8.9 high, 4.0–6.9 medium, 0.1–3.9 low. What the number does not tell you is whether you are exposed. Two metrics in the vector do most of the work of deciding that:
- AV (Attack Vector) —
Nmeans network-reachable,Lmeans the attacker already needs local access. A local-only flaw in a build tool is a very different problem from a network flaw in your request path. - UI (User Interaction) —
Nmeans no victim action needed;Rmeans someone has to click something. Required interaction usually drops real-world urgency considerably for a backend service.
The vector explainer decodes all eight metrics for any finding, which is the fastest way to decide whether a scary red number deserves a hotfix or a ticket.
Dev Dependencies Are Not Automatically Safe
The common instinct is to dismiss anything under devDependencies because it never
ships to production. That is right about the runtime and wrong about the threat. A compromised
build-time package runs with full permissions on your CI machine and your laptop, with access to
environment variables, deploy credentials and the artifact it is about to publish. The
event-stream incident in 2018 and the repeated ua-parser-js and
node-ipc compromises all worked through exactly that path. Judge a dev dependency by
what it can reach during a build, not by whether it appears in your bundle.
Fixing Efficiently: One Bump, Several CVEs
Vulnerabilities cluster. A package sitting three years behind will usually carry four or five advisories, all fixed by a single upgrade to the highest patched version. That is why each package here shows one upgrade target rather than a fix per finding: it is the highest “fixed in” version across everything affecting you, so one bump clears the lot. Work the list in this order, which is close to what a security engineer would do:
- Critical and high findings on network-reachable runtime dependencies — these are the ones with a plausible path from the internet to the flaw.
- Anything with a known public exploit, regardless of score. Availability of a working exploit changes the calculus more than a decimal point does.
- Transitive dependencies you cannot bump directly — these often need a parent upgrade, an npm
overridesblock or a Composerconflictconstraint. - Everything else, batched into one maintenance PR rather than five.
What This Tool Cannot See
It reads a manifest, so it sees your direct dependencies only. The majority of real-world exposure lives in transitive dependencies — the packages your packages pull in, often hundreds of them. To cover those, paste a resolved dependency list from your lockfile, or run your package manager’s own auditor in CI where it can walk the full tree. It also cannot know whether a vulnerable function is actually called in your code, which is what commercial reachability analysis adds. And no advisory database is complete: a package with zero findings has no published advisories, which is not the same as being safe.
Shipping code as well as auditing it? The HTTP Security Grader checks the headers your app actually sends, and the Email Deliverability Analyzer covers SPF, DKIM and DMARC. Browse all Dev & Tech tools for more.
Frequently Asked Questions
What is a CVE and what does the CVSS score mean?
A CVE is a public identifier for one specific vulnerability, assigned by a CVE Numbering Authority. The CVSS score that accompanies it is a 0 to 10 severity rating derived from a vector describing how the flaw is exploited: 9.0 and above is critical, 7.0 to 8.9 high, 4.0 to 6.9 medium. The score measures the flaw in isolation, not the risk to your specific application.
Does a high CVSS score always mean I am actually exploitable?
No, and this is the most common misreading. CVSS base scores assume the vulnerable code path is reachable by an attacker. A prototype pollution flaw in a build-time-only dev dependency scores the same as one in your public API handler, but only one of them is a real risk. Check whether the vulnerable function is on a path that handles untrusted input before you treat a number as an emergency.
Why does the tool skip some of my dependencies?
Version matching needs a concrete version. Entries like "*", "latest", "workspace:*", a git URL or a local file path have no version to compare against a vulnerability range, so they are listed as unpinned rather than silently marked clean. Scan your lockfile-resolved versions if you want full coverage.
How is this different from npm audit or pip-audit?
It reads the same advisory data — OSV.dev aggregates the GitHub Advisory Database, PyPA and Packagist feeds — but it works on a pasted manifest with no install step, no lockfile and no repository access, and it covers three ecosystems side by side. Run your package manager's auditor in CI; use this when you want a fast read on a project you have not checked out.
A CVE has no fix version listed — what do I do?
That means no patched release exists yet, which happens with abandoned packages and very recent disclosures. The options are to pin to a fork, apply a patch locally with a tool like patch-package or a Composer patch, remove the dependency, or add a compensating control such as input validation at the boundary. Track the advisory so you can drop the workaround when a fix ships.
