High known vulnerability

What mcp-scan saw

Same OSV.dev query as the critical variant: the package name and the npm ecosystem, with no version. An advisory routes here when its parsed CVSS base score lands between 7.0 and 8.9, or when no score parses and database_specific.severity says HIGH.

Why it fires

A high score usually means either remote reachability with some precondition, or full compromise with local access. For an MCP server both preconditions are often already met, since the server runs with your user account and accepts input the model composes. The scan runs on every invocation, so this appears the moment an advisory lands upstream.

When this is a false positive

• No version is sent in the OSV query, so advisories fixed long before your version still come back. This is the dominant false positive for the whole known-vulnerability family.
• The advisory may cover a subpath the server never imports, for example a bundled CLI or an optional adapter.
• When CVSS parsing fails, the score comes from the reporting database's own label rather than a vector, and those labels skew high.
• CVSS v4 vectors are not parsed by the current extractor and fall through to the qualitative path, so a v4-only advisory is graded by label rather than by score.

How to fix it

1. Open the advisory id from the finding text at osv.dev and read the affected ranges.
2. Check which version you run: look for an @version pin in the args, or run npm view on the package to see what latest resolves to.
3. If affected, pin the fixed version in the args array rather than relying on npx resolving latest.
4. If not affected, the finding stays until the package's advisory set changes. There is no per-advisory ignore, so either pin and move on or add 'known-vulnerability-high' to suppressRules in .mcp-scan.json.
5. Use --offline to read the bundled snapshot instead of querying OSV when you need a reproducible result.