MCP Malware Risks (STDIO)
How STDIO MCP servers create unmanaged attack surfaces - supply chain attacks leading to RCE, the rug pull attack, and why "local" doesn't mean "safe from data exfiltration."
Two types of MCP servers
The MCP protocol supports two transport mechanisms for connecting AI clients to tool servers:
STDIO (Standard I/O) - the AI client spawns a local process on the user's machine. The client and server communicate over the process's stdin/stdout pipes. The server code runs locally with the user's full permissions, filesystem access, and network access.
HTTP (Streamable HTTP / SSE) - the AI client connects to a remote server over HTTP. The server runs on managed infrastructure, and all communication passes through the network where it can be observed, filtered, and controlled.
Most MCP servers available today - installed via npx or uvx - use the STDIO transport. This has significant security implications.
Supply chain attacks → Remote Code Execution
The most critical risk with STDIO MCP servers is that installing one is equivalent to granting arbitrary code execution on the user's machine. The npx / uvx execution model is the "curl | bash" anti-pattern applied to AI tooling:
- No lockfile, no hash verification, no signature check
- Each invocation can silently pull a newly-published malicious version
- The spawned process has full filesystem, network, and environment access
This has already led to real-world attacks:
- postmark-mcp (Sep 2025) - First malicious MCP server in the wild. Typosquatted npm package that silently BCC'd all emails to an attacker domain.
- Shai-Hulud worm (2025–2026) - Self-replicating npm worm that injected malicious MCP servers into Claude Code, Cursor, and Windsurf. Exfiltrated 14,000+ secrets across 487 organizations.
- mcp-remote RCE (CVE-2025-6514) - Critical CVSS 9.6 vulnerability in the
mcp-remotepackage (437K+ downloads). First documented full RCE against an MCP client. - Systemic MCP flaw (Apr 2026) - OX Security disclosed a vulnerability enabling arbitrary RCE on ~200K MCP server instances. Anthropic declined to patch, calling it "expected behavior."
"Local" doesn't mean safe from data exfiltration
The vast majority of popular MCP servers (GitHub, Slack, Notion, Linear, databases) are thin local wrappers around remote HTTP APIs. When a developer runs npx @modelcontextprotocol/server-github, they spawn a local process that:
- Makes outbound HTTPS calls to GitHub's API
- Carries a Personal Access Token in its environment
- Has full filesystem and network access
- Produces traffic indistinguishable from any other HTTPS request
From a network monitoring perspective, "local" doesn't mean safe from data exfiltration. The STDIO transport only describes how the AI client communicates with the process - it says nothing about what that process does with the network.
The landscape is shifting: many popular MCP servers are migrating from STDIO to remote HTTP transports, which is a positive trend for security governance. However, the transition is gradual - the majority of community and third-party servers still default to STDIO, and enterprises cannot wait for the ecosystem to catch up.
The "rug pull" attack
MCP servers can change their tool definitions after the user has approved them:
- Server returns clean, harmless tool definitions on first connect
- User reviews and approves
- On subsequent
tools/listcalls, server returns modified definitions with exfiltration instructions - The AI agent treats the new instructions as legitimate
No mechanism in the MCP protocol verifies schema integrity after the initial handshake.
Why this is shadow IT
From a security leader's perspective, STDIO MCP servers are ungovernable:
| Capability | STDIO servers | Managed HTTP servers |
|---|---|---|
| Network-level blocking | Impossible (outbound HTTPS) | Block at proxy/firewall |
| Auth revocation | Hunt creds on each machine | Instant at IdP/gateway |
| Audit logging | None | Every tool call logged |
| DLP/content inspection | Impossible | Gateway inspects all traffic |
| Supply chain control | Any npm package runs | Vetted registry, version pinning |
| Credential rotation | Manual, per-machine | Automatic, centralized |
| Policy enforcement | None | RBAC, rate limits, geo-restrictions |
STDIO MCP servers are, in effect, shadow IT - employees installing unvetted software with privileged access to corporate APIs, completely invisible to security teams.
How Edison Watch mitigates these risks
Edison Watch sits between AI clients and MCP servers as a security gateway:
- Dependency pinning - locks MCP server package versions on first run, preventing silent supply chain updates
- Quarantine - new MCP servers are quarantined until an admin explicitly approves them
- Policy engine - CEL-based rules enforce what data can flow where, regardless of transport
- Lethal Trifecta enforcement - blocks exfiltration by detecting when private data access + untrusted content + external comms converge in a single session
- Audit logging - every tool call is logged with full context for incident response
Further reading: MCP Servers: The New Shadow IT for AI - Qualys
AI Security Threats
Understanding the novel security threats introduced by AI agents and the MCP protocol - from malware-laden STDIO servers to data exfiltration via the Lethal Trifecta.
The Lethal Trifecta
The three-capability threat model that enables AI-driven data exfiltration - private data access, untrusted content exposure, and external communication.