npm Package Vulnerability Checker

An npm release can become the subject of a security advisory long after it entered a project. Reviewing dependencies connects those published warnings to the versions a project declares or records, so investigation begins with a specific release rather than a package name alone.

A vulnerability advisory describes a reported flaw and the releases known to be affected. OSV.dev brings together records from originating advisory databases. A match supplies evidence to investigate, while the application’s actual exposure depends on how the dependency is installed, configured and used.

Package identity matters because the same name can have many releases with different vulnerability histories. A package coordinate combines its name, exact version and ecosystem, such as npm. For a scoped package, the @scope/ prefix is part of its identity. An exact declaration such as 1.2.3 identifies one version string, whereas a range such as ^1.2.3 allows multiple releases and a tag such as latest can move.

Direct dependency

A dependency declared by the project itself, including dependencies used for development.

Transitive dependency

A dependency brought in by another dependency. Addressing its vulnerable version may require updating the dependency that introduces it.

The distinction changes which evidence is useful. A package.json manifest records declarations and acceptable versions. It does not establish the installed dependency tree or enumerate every transitive dependency. A package-lock.json records resolved versions and dependency locations, providing stronger evidence about a particular resolution. Even a lockfile must be connected to the build being reviewed before it can support claims about a running application.

A severity label helps describe a vulnerability, but prioritization also needs the advisory’s conditions. Relevant questions include whether the affected release is present, whether the vulnerable function can be reached, and whether the required configuration or operating system applies. Development dependencies can matter to build and test environments even when they are absent from the production runtime.

Remediation needs the same care. A release reported as fixing one affected interval may belong to a different release branch or require compatibility changes. Published advisories can also be revised, withdrawn or added after an earlier check. Dependency review therefore combines advisory evidence, the project’s resolved versions and testing of the proposed change; an empty lookup cannot establish that an application is secure.

How to Use This Tool:

Start with the npm manifest or lockfile for the project you want to investigate. This checker requests OSV matches for reviewed coordinates. It does not interpret a pre-existing npm audit report or run npm’s registry audit.

1. Paste your document into npm JSON source, or use Browse or drag and drop to load one .json file of at most 1 MiB. Replace the editable sample with your own evidence before reviewing the coordinates.
   A rejected file leaves the existing text in place. Confirm that npm JSON source contains the document you intended to check.
2. Choose Auto detect under Input format, or select the expected manifest or lockfile version. Correct any JSON or structure error before continuing.
   If the selected format does not match the document, choose Auto detect or the matching format. Changing the selector does not convert a lockfile.
3. Review every entry under Coordinates to send, including private names. Expand the unresolved and excess entries to see what will remain unscanned. If no supported exact coordinates are available, obtain resolved-version evidence from a supported lockfile.
4. Set any deadline or detail-limit override under Advanced, or leave both blank for the defaults. Changing the source, format or either override clears the previous result and resets consent.
5. Enable Review and consent, then select Look up reviewed coordinates. Approval alone does not send a request.
6. Read the completed-query count in Scan summary and the reasons in Package coverage before investigating matches in Advisory review. Check whether advisory details loaded as well as whether the queries finished.

Interpreting Results:

Coverage determines how much a result can establish. A query asks OSV about one exact coordinate; fetching the advisory details is a separate operation. OSV lookup finished can therefore appear even when some detail records are unavailable.

Unavailable details do not remove a returned advisory ID. The match remains visible, while severity, withdrawal and affected-version evidence may be unknown. Open the original record when its ID falls outside the detail allowance. For a failed detail request, retry with an appropriate deadline. A low detail limit does not make the underlying query incomplete.

Query distribution counts distinct resolved name/version coordinates. Its categories are Complete · matches, Complete · none returned, Partial, Unknown and Unscanned · coordinate cap. Their total includes exact coordinates above the cap and excludes unresolved declarations. Duplicate occurrences have already merged. A partial query with matches belongs to Partial, although it contributes to the summary’s count of coordinates with returned IDs. The chart does not measure advisory totals, severity, installed copies or application risk.

For a returned match, confirm the recorded version against the project or deployment, read the upstream advisory conditions, and find the dependency responsible for introducing that version. Review a compatible change to the owning dependency, regenerate the lockfile through the normal dependency workflow, rebuild and test, then check the new evidence. The checker does not install packages, change dependencies or evaluate whether vulnerable code is reachable.

The summary can be copied as text or copied and downloaded as JSON. Coverage and advisory tables support CSV, DOCX and individual-row copying; advisory table exports require at least one advisory. The distribution can be downloaded as PNG, WebP, JPEG or CSV once the chart is ready. If the chart is unavailable, the coverage rows remain available.

The JSON handoff identifies OSV.dev and npm and includes the check time, effective limits, query outcomes, summarized advisory evidence and package coverage. It is not a full raw OSV response archive or a copy of the input file. CSV text starting with =, +, - or @ receives a leading apostrophe to reduce spreadsheet formula risks, even when those characters follow whitespace or control characters. A scoped npm name may therefore have a protective apostrophe in CSV; JSON preserves the name without that prefix.

Technical Details:

Known-vulnerability matching associates a package identity and version with advisory evidence. Its reliability depends first on extracting a supported exact coordinate, then on completing the provider’s response. Dependency resolution, advisory matching and confirmation of an installed application are different operations.

Rule Core

A package.json manifest records declarations, while a package-lock.json lockfile records resolved dependency evidence. Automatic detection uses lockfileVersion when present and otherwise expects a manifest. Selecting a format explicitly requires the document to match it.

The JSON root must be an object. Other lockfile versions and ecosystems are unsupported. Empty supported dependency objects can parse successfully while supplying no coordinates to query. In a manifest, dependencies, devDependencies, optionalDependencies and peerDependencies must be objects when present.

Eligible names use lowercase letters and digits, with dots, underscores and hyphens allowed after the first character of each name or scope. Scoped names retain their @scope/ prefix, and the complete name may contain at most 214 characters. An accepted version is a literal three-part Semantic Versioning (SemVer) string of at most 128 characters. Valid prerelease and build identifiers are retained exactly, as in 1.2.3-beta.1+build.01.

Major, minor and patch numbers cannot contain leading zeroes, and an entirely numeric prerelease identifier cannot either. Build identifiers may contain leading zeroes. Version strings are not trimmed or repaired, so surrounding spaces, v1.2.3, =1.2.3, partial versions, ranges and tags remain unresolved. Manifest aliases, URLs and local-source declarations are also unscanned; no registry request resolves them to a release.

Lockfile entries marked as links, entries with recognized workspace, file, link or Git origins, and aliases whose recorded name differs from the installation name are unscanned. These exclusions do not authenticate the origin of an accepted package. An exact version extracted from a lockfile does not verify registry provenance, file integrity or what is currently installed. Eligible lockfile records are not filtered by development or optional-dependency flags.

Deduplication uses the complete name and version string. Identical pairs merge across locations and sections; distinct versions remain separate, including differences in retained prerelease or build text. Coordinates are sorted by their full name/version text before the first 200 are selected. This ordering is not a severity ranking. Remaining exact pairs are retained as excess, while unresolved declarations retain their names and reasons without their original specifications.

Query completion and limits

OSV batch responses identify matching advisories. Additional result pages belong to individual coordinates, so a query is complete only after a valid final response with no further page and no rejected advisory references. An empty earlier page is insufficient when more pages remain. Malformed responses, repeated continuation information, timeouts and limits leave incomplete coverage visible.

The limits below bound the work; they do not define an acceptable security result. Increasing the per-request deadline can help a slow request, but the overall deadline still includes both querying and advisory-detail retrieval.

Returned IDs are deduplicated across queries, then sorted by ID for detail retrieval up to the chosen allowance. Details are not selected by severity. For query failures, the retained coverage reason helps distinguish provider errors, rate limiting, unreadable responses and network failures from a completed empty query.

Advisory evidence and fixed boundaries

An advisory row preserves the returned ID and the coordinates associated with it. Aliases are reported alternative IDs for the same vulnerability, but alias relationships do not merge distinct returned IDs here. The advisory total is therefore an ID count. OSV normally excludes withdrawn records from fresh queries. If a returned ID has withdrawn details, it remains in the review and its counts, with the withdrawal time retained. A loaded record without withdrawal information shows No withdrawal reported, while missing details leave withdrawal status unknown.

Source severity retains labels supplied in the advisory and matching npm package evidence. Several labels may coexist. When no label is supplied, the result remains Unknown, even if a severity vector is present. Reported vector types and values, including Common Vulnerability Scoring System (CVSS) vectors, are shown separately. No numerical CVSS score or severity category is calculated from them.

Affected-package evidence is selected by npm ecosystem and matching package name. The displayed fixed boundaries come from semantic-version or ecosystem-defined affected ranges; explicit affected versions are shown separately. The concise review does not reproduce full ranges or independently establish that every displayed boundary applies to each queried version.

The original advisory supplies the context for a boundary. These distinctions prevent a listed endpoint from becoming an unsupported upgrade recommendation.

Missing explicit versions do not mean that no versions are affected, and a missing fixed boundary does not prove that remediation is unavailable. A withdrawn entry needs review of the publisher’s explanation. Neither a match nor a withdrawal establishes exploitability, reachability, installation or application safety.

The detail review retains up to 1,000 summary characters, 100 aliases, 20 source links, and 30 fixed boundaries plus 30 explicit affected versions per matching affected-package entry. Source links are limited to HTTPS addresses without embedded credentials. These limits also affect summarized evidence in the JSON handoff. Full evidence remains in the original OSV record and its originating advisory sources, whose data licences apply. Results reflect the data returned at the check time, not a guarantee that every newly published or corrected advisory has already been included.

Privacy Notes:

Parsing the document and reviewing coordinates happen in the browser. An OSV lookup requires explicit approval and the lookup action. The initial query uses POST requests containing the reviewed package names, exact versions and npm ecosystem. Further query pages also carry the continuation information supplied by OSV. Subsequent GET requests retrieve advisory details by the returned advisory IDs.

• Private package names are visible to OSV when they are among the approved coordinates. Advisory-detail requests also reveal which IDs are being retrieved.
• The full document, local paths, registry URLs, credentials in declarations and application source code are excluded from these requests. Browser credentials and referrer information are omitted, while OSV still receives normal network connection information, including the connecting IP address.
• Only Input format, Request deadline override and Advisory detail limit override are shareable settings in the link. Source text, consent, results, the selected result tab and operational status are excluded. Opening the link does not reproduce someone else’s report or approve a lookup.
• Exported reports can contain private names, including unresolved names that were never queried. Review the report contents before sharing them.

Cancel stops pending work, clears the cancelled result and resets consent. It cannot retract requests already sent to OSV. The checker does not establish how OSV retains received requests.

Worked Examples:

{
  "dependencies": {
    "lodash": "4.17.20",
    "minimist": "^1.2.0"
  },
  "devDependencies": {
    "@babel/core": "7.12.0"
  }
}

References:

• package.json dependency declarations, npm.
• package-lock.json format and dependency evidence, npm.
• Semantic Versioning 2.0.0, Semantic Versioning.
• OSV batch-query documentation, OSV.
• OSV advisory-detail documentation, OSV.
• Open Source Vulnerability format, version 1.9.2, OpenSSF, October 13, 2026.
• OSV data sources and correction guidance, OSV.
• Auditing package dependencies for security vulnerabilities, npm, October 23, 2023.
• How to audit Node.js dependencies, Simplified Guide.