← All rules

mcp-scan rule

Critical known vulnerability

known-vulnerability-criticalcritical

What mcp-scan saw

The package scanner POSTed the npm package name to api.osv.dev/v1/query and read the returned advisories. For each one it parsed a CVSS base score from the severity array (numeric scores and v3 vectors; v4 vectors fall through), and routed a score at or above 9.0 to this rule. When no score parses, it falls back to database_specific.severity, and to MEDIUM when that is missing too.

Why it fires

A critical CVSS score means the advisory rates the flaw as remotely reachable with low complexity and no privileges, which is exactly the profile of a dependency running with your filesystem and your API keys. The scan happens on every run, not just with --ci, so a newly published advisory surfaces the next time you scan without you changing anything.

When this is a false positive

  • The OSV query sends only the package name and ecosystem, with no version. Every advisory ever filed against that package comes back, including ones fixed years before the version you run.
  • npx without a pinned version resolves latest at launch, so the scanner has no installed version to compare against and cannot rule the advisory out.
  • The advisory may be against a code path the MCP server never enters, for example a CLI parser flaw in a library the server only uses as an API.
  • When OSV gives no CVSS vector, the score comes from database_specific.severity, which is the reporter's own label and is frequently more severe than the vector would have been.

How to fix it

  1. Read the advisory id from the finding text and open it at osv.dev to get the affected version ranges.
  2. Determine which version you actually run: check the args for a pinned @version, or run npm ls on the package if it is installed locally.
  3. If your version is inside the affected range, pin the fixed version directly in the args array, for example npx -y package@1.2.3.
  4. If your version is outside the range, this finding is noise for you until the package changes. Record why in your own notes, since the scanner will report it again on the next run.
  5. For an air-gapped or offline run, use --offline so the check reads the bundled CVE snapshot instead. Refresh that snapshot with npm run update-cve-snapshot when it is more than 30 days old.