Loading page
About this tool
Query exact package versions against the official OSV API through a bounded same-origin endpoint with explicit network and coverage limitations.
The Dependency Vulnerability Lookup checks exact package versions against the public OSV.dev querybatch API and returns the advisory IDs that match, with a direct link to each record on osv.dev. You give it one line per package in the form ecosystem | package name | exact version, up to 20 packages per batch across npm, PyPI, Maven, Go, NuGet, crates.io and RubyGems. It is for developers auditing a specific dependency set who want the advisory IDs to read, not a scanner that grades their project.
Open Dependency Vulnerability Lookup on AltFTool — it loads instantly in your browser.
Enter one row per package as ecosystem | package name | exact version in the Query rows box (up to 20 rows), or use Import npm lockfile locally to fill it from package-lock.json.
Press Lookup exact versions to send the batch to the OSV.dev API — tags and ranges like latest or ^1.2.0 are rejected up front.
Read each package's matching advisory IDs in the Per-package response cards, or click Download response for the raw JSON.
Tags, ranges and wildcards like latest, ^1.2.0 or 1.x are rejected, so a result always corresponds to one specific published version.
npm, PyPI, Maven, Go, NuGet, crates.io and RubyGems can be mixed in a single lookup of up to 20 queries.
Every result ships with its limitations — a match is an advisory ID, not an exploitability verdict, and no match may simply mean a coverage gap.
Up to 20 queries per batch, with a 20,000-character limit on the input text and up to 200 advisory IDs returned per package. Anything beyond those caps is marked incomplete rather than silently trimmed.
Seven: npm, PyPI, Maven, Go, NuGet, crates.io and RubyGems. Maven names must use the groupId:artifactId form and npm versions must be an exact semantic version such as 1.2.3.
OSV answers questions about one published version, so tags, wildcards and ranges are rejected up front — supply the exact version resolved in your lockfile instead. That keeps a result unambiguous rather than approximately true.
No. An empty result means this OSV query returned no matching advisory IDs, which can also reflect database coverage, package identity mismatches, version syntax, or a publication delay for a newly disclosed issue. Treat matches as leads to read, not as a safety or exploitability conclusion.