Known malicious package

What mcp-scan saw

The registry scanner resolved a package name (for npx and npm, the first argument not starting with a dash; otherwise the command itself), stripped any @version tag, and found an exact match in KNOWN_MALICIOUS_PACKAGES. That set is a hardcoded list of five confirmed packages carrying a LAST_UPDATED date in the source.

Why it fires

These are packages with published incidents: hidden BCC exfiltration, SSH key theft, credential harvesting, wallet theft, and .env exfiltration. The check is first in the registry scanner's if-chain, so a malicious match short-circuits the official, trusted, and unverified branches. The finding is marked not fixable, because the only remediation is removal.

When this is a false positive

• The list is a static snapshot with a LAST_UPDATED date, not a live feed. A name that was reclaimed by a legitimate publisher after the incident still matches, since the comparison is on the name alone.
• Matching happens after @version stripping but before scope handling, so a private package of your own that shares a bare name with a listed one is treated as the listed one.
• The list carries no ecosystem qualifier. A non-npm command whose binary name collides with a listed package name matches through the else branch that assigns packageName from server.command.

How to fix it

1. Remove the server entry from the client config now. Do not disable it and leave it in place.
2. Check the incident note in the finding text for what the package did, then treat every credential that server could read as compromised and rotate it.
3. Search your machine for a cached copy: npx leaves packages in the npm _npx cache, so clear it before reinstalling anything with a similar name.
4. If you believe the name has been reclaimed by a legitimate publisher, verify the current publisher on npmjs.com and open an issue on the mcp-scan repo. Do not suppress this rule locally to get past it.