Patch known vulnerabilities in an MCP package

What we checked

We cross-referenced your published package against public advisory databases for known vulnerabilities (CVEs). In v1 this is a package-level check: we match advisories against the package and version we scored; full dependency-tree coverage is on the roadmap. The signal passes when no known vulnerability affects the version we scored. Otherwise:

CVE check failed: an unpatched critical CVE affects this package; the score is capped at 0.

A known CVE affects this package

CVE check failed: a known advisory affects this package; its severity couldn't be graded.

No known CVEs affecting this package version or its production dependencies.

CVE data not yet available for this package.

Why it matters

A known CVE is a vulnerability with a public advisory, and often a public exploit. Because an MCP server is code you run with real permissions, an unpatched flaw in it (or in any transitive dependency) is a direct path for an attacker. Most of these have an obvious fix: a newer version already exists. Keeping current is the single most effective supply-chain hygiene step, and it goes hand in hand with keeping the package actively maintained.

What counts as a critical CVE?

Severity follows the industry-standard CVSS scale: the NVD rates a base score of 9.0 to 10.0 as critical, 7.0 to 8.9 as high, and downwards from there. We read an advisory’s published severity the same way, so a CVE the ecosystem grades critical is what triggers the hard cap described below.

How do I find known vulnerabilities in an npm or PyPI package?

Every major registry ships a first-party auditor that scans your installed dependencies for known vulnerabilities against public advisory databases, naming each affected package, its advisory, and the version that fixes it. You don’t need a third-party service. The exact command for npm, PyPI, NuGet, Go and Rust is in the fix below.

How to fix it

Audit your dependencies, then bump the affected packages to a patched version. Pick your ecosystem:

# List known vulnerabilities in the dependency tree
npm audit

# Apply safe, semver-compatible fixes
npm audit fix

# If the fix needs a major bump, update the dependency explicitly
npm install some-dependency@latest

# Audit installed/declared dependencies (pip install pip-audit)
pip-audit

# Then bump the affected package to a patched version
pip install --upgrade some-dependency
# and pin the new floor in pyproject.toml / requirements

# Report vulnerable packages, including transitive ones
dotnet list package --vulnerable --include-transitive

# Update the affected package to a patched version
dotnet add package Some.Dependency --version 1.2.3

# Scan for vulnerabilities that actually reach your code
# (go install golang.org/x/vuln/cmd/govulncheck@latest)
govulncheck ./...

# Update the affected module, then tidy
go get -u some/module
go mod tidy

# Audit Cargo.lock against the RustSec advisory DB
# (cargo install cargo-audit)
cargo audit

# Pull in patched versions allowed by your version requirements
cargo update

How we re-check

We re-scan the scored package against current advisory data on our next crawl. Once that version no longer matches a known CVE, the signal flips to a pass on the following score refresh, and any score cap from an unpatched critical CVE is lifted.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt

Context: this repository publishes an MCP server. VerifyMCP's vulnerability
check failed, which means public advisory databases carry a known advisory
against the published package and version we scored. An unpatched critical
advisory also caps the score at 0 until it is resolved.

Goal: the published package no longer matches a known advisory, so the
next crawl records no known advisories and any critical cap is lifted.

Do this:
1. Run your ecosystem's first-party audit tool to list affected packages,
   their advisories, and the version that fixes each one: `npm audit`,
   `pip-audit`, `dotnet list package --vulnerable --include-transitive`,
   `govulncheck ./...`, or `cargo audit`.
2. Apply the safe, compatible fix first: `npm audit fix`, `pip install
   --upgrade <dep>`, `dotnet add package <dep> --version <patched>`,
   `go get -u <module> && go mod tidy`, or `cargo update`.
3. If the only fix is a major or breaking bump, stop and ask me before
   applying it; I need to sign off on the compatibility risk.
4. Commit the updated lockfile so the patched versions are pinned.
5. Prepare the release, then stop and let me run the publish myself, since
   the check reads the published package.
6. Wire the audit command into CI (Dependabot, Renovate, or a
   `govulncheck` pipeline step) so future advisories surface before release.

Rules:
- Never run the publish command (`npm publish`, `twine upload`, `dotnet nuget
  push`, `cargo publish`, a release tag that triggers one) yourself. A
  published version is permanent and notifies every downstream consumer:
  prepare the change, show me the diff, and let me publish it.
- Never suppress, ignore-list, or allowlist a CVE to make the finding
  disappear instead of patching it or genuinely triaging it as a non-issue.
- Never claim an advisory is patched without re-running the audit tool and
  confirming it reports clean.
- If no patched version exists yet, tell me rather than forcing an unsafe
  downgrade or fabricating a fix.

Report back: which advisories were found, which packages you bumped and to
what versions, and the audit tool's clean output confirming no remaining
findings.

Reference: https://verifymcp.io/docs/packages/vulnerabilities