Skip to main content

MCP-006 Known-compromised MCP server release

An MCP server entry in your host config pins to a registry package whose (ecosystem, name, version) triple matches a catalogued supply-chain incident. The catalog is the same one MCP-006's sibling rules (SUP-COMPROMISE-001 through 005) and EXT-001 consume; this rule applies the lookup to MCP server entries specifically.

What Vulkro detects​

Rule fires when:

  1. The server's command is npx (looked up as ecosystem npm) or uvx (looked up as ecosystem pypi).
  2. The first positional argument is a registry-package spec (not a local path, not a git URL).
  3. The (name, version) split from that spec matches a row in the curated compromised-release catalog at tools/cve-bundler/data/compromised-releases.json.

Catalog data refreshes via the signed update bundle (vulkro update); a baked-in fallback ships in the binary so fresh installs and offline machines still get the seed incidents.

Severity: Critical. Confidence: High. Evidence signal: mcp-server-compromised-release, weight 0.9, source Context.

The finding cites the catalog row's incident ID and the first reference URL so the operator can read the advisory without leaving the terminal.

Non-compliant config​

{
  "mcpServers": {
    "evil-ua-parser": {
      "command": "npx",
      "args": ["[email protected]"]
    },
    "evil-ctx": {
      "command": "uvx",
      "args": ["ctx==0.2.2"]
    }
  }
}

Both pins are exact-version hits against catalogued incidents: [email protected] is part of the 2021 maintainer-account hijack, and ctx==0.2.2 is the 2022 PyPI malicious-postinstall that exfiltrated AWS credentials.

Compliant config​

{
  "mcpServers": {
    "ua-parser": {
      "command": "npx",
      "args": ["[email protected]"]
    }
  }
}

Avoid the catalogued compromised versions entirely. If the upstream has not issued a clean release, remove the dependency or vendor it from a known-good source.

Remediation​

  1. Replace the pinned version with a clean release published before the compromise window or after the upstream's incident-response patch. The advisory URL in the finding points at the precise affected range.
  2. Audit your machine and CI for any build artefacts produced while the compromised version was resolved. Tokens stored on developer machines or in CI runners may have been in scope of the malicious payload.
  3. Rotate any credentials that lived in the same env the host could see while the bad version was active.
  4. Run vulkro respond against your other projects to find every place the same (name, version) is in use.

See also​

References​

Last updated on