Respond to an MCP package malware finding

Q: What we checked

We record a third-party malware verdict for your package, sourced from our malware-scanning provider's supply-chain analysis. The signal passes when no malware is detected. Otherwise, the possible outcomes are a malware finding, a critical malware finding, or an inconclusive scan:

What we checked

We record a third-party malware verdict for your package, sourced from our malware-scanning provider’s supply-chain analysis. The signal passes when no malware is detected. Otherwise, the possible outcomes are a malware finding, a critical malware finding, or an inconclusive scan:

Malware check failed: a supply-chain vendor flagged critical malware; the score is capped at 0.

A supply-chain vendor flagged a malware risk

No malware found by supply-chain analysis.

Malware scan not yet available for this package.

This is a vendor finding, not our own static judgement; we surface the scanning provider’s verdict and weight it in the package rubric. The steps below are about understanding and resolving that specific finding.

Why it matters

A malware verdict means an automated supply-chain scanner saw behaviour consistent with malicious code: for example, an install hook that reads credentials, obfuscated network calls, or a known-bad transitive dependency. Because an MCP server runs with real permissions on the machines that install it, a true positive here is serious: it can mean an account takeover, a hijacked publish, or a compromised dependency shipping in your name.

Is a malware verdict ever a false positive?

Yes. Automated scanners do over-flag, so a verdict is a strong prompt to investigate rather than proof of guilt. Until you have read the finding and ruled compromise out, though, treat it as real: the steps below help you tell a genuine incident from a benign-but-unusual pattern.

How to fix it

Be methodical; the right response depends on whether the finding is real:

Read the specific finding. Open the vendor report and identify exactly what was flagged: which file or dependency, and which behaviour. That tells you whether you’re looking at compromise, a risky-but-intentional pattern, or a false positive.
Check for compromise. Review recent publishes and dependency changes. Look for versions you didn’t publish, an unexpected new (or updated) transitive dependency, or changes you don’t recognise; the common causes are account takeover and a malicious transitive dependency.
Rotate credentials and lock down publishing. If there’s any chance the publish path was compromised, rotate your registry tokens and require 2FA on the publishing account:

# Verify the registry signatures of what you have installed
npm audit signatures

# Revoke any token that could have been exposed, then mint a fresh one
npm token list
npm token revoke <token-id>
npm token create

# Require two-factor auth for both login and publish
npm profile enable-2fa auth-and-writes

Remove the bad version. If compromise is confirmed, deprecate or unpublish (yank) the affected version so consumers stop pulling it, and publish a clean release from known-good source. If a malicious version actually reached users, report it to the registry so npm can take it down and issue an advisory.
Dispute a false positive. If you’ve verified the finding is benign, dispute it with the scanning provider so the verdict is corrected, then ask for a re-scan.

How we re-check

We refresh the vendor verdict on our next crawl. Once the scanning provider reports the scored version as clean (because you shipped a remediated release, or the dispute was upheld), the signal flips to a clean verdict on the following score refresh, lifting any critical cap.

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 malware check
flagged your package, sourced from our malware-scanning provider's
supply-chain scan.
This is a vendor finding, not proof of guilt, but a critical verdict caps
your score at 0 and must be treated as a possible active incident.

Goal: the specific finding is genuinely resolved (a real compromise cleaned
up, or a false positive disputed with the vendor), so the next crawl
records a clean scan.

Do this:
1. Stop. Do not publish, unpublish, or edit anything yet. Open the
   scanner's report and identify exactly what was flagged: which file or
   dependency, and which behaviour triggered it.
2. Check for compromise: review recent publishes and dependency changes for
   versions you did not publish, an unexpected new or updated transitive
   dependency, or commits you do not recognise.
3. Summarise the finding and what you found for the human before taking any
   remediation action.
4. If the human confirms compromise, help them rotate registry tokens,
   enable two-factor auth on the publishing account, and prepare a clean
   release from known-good source.
5. If the human agrees it is a false positive, prepare the dispute details
   for them to submit to the scanning vendor; do not submit it yourself.

Rules:
- This may be a genuine security incident: never suppress, delete, or
  quietly repackage the flagged code to dodge the scanner, and never
  republish under a new version to sidestep review.
- Always stop and escalate to the human before rotating credentials,
  unpublishing a version, or disputing a finding; these are their calls.
- Never report the incident as resolved without the human's confirmation.

Report back: exactly what the scanner's finding said, whether you found
evidence of compromise, and what decision you are waiting on the human for.

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