What is a shadow MCP server?
A shadow MCP server is an unapproved, unmanaged, or unsupervised Model Context Protocol server operating inside an organization without formal security review or visibility.
OWASP includes Shadow MCP Servers as a dedicated risk in its MCP Top 10. The problem is not that every unapproved server is malicious. The problem is that an MCP server can expose privileged capabilities while sitting outside normal ownership, authentication, monitoring, and vulnerability-management processes.
A server can be a shadow MCP server even if it has no known software vulnerability. “Shadow” describes the lack of oversight, not the presence of a CVE.
Where shadow MCP servers come from
- Local developer setups: A developer installs a local MCP server so an AI coding tool can read files, search repositories, or call an internal API.
- Public registries and community projects: A useful integration is pulled from GitHub or a package registry because it solves an immediate workflow need.
- Internal experiments: A team builds its own server for a prototype and keeps using it after the experiment becomes real work.
- Remote shared services: A local helper is moved into a container, development VM, or shared host and becomes network-reachable without a corresponding security review.
Each path is understandable. The risk appears when the server’s access grows without corresponding ownership, review, or monitoring.
Why shadow MCP servers are high-impact
MCP servers often sit between an agent and systems the organization cares about. They may read files, call SaaS APIs, access source code, modify tickets, run commands, or interact with CI/CD systems.
Pluto’s MCP research provides concrete examples of the risks associated with shadow MCP servers. MCPwnfluence demonstrated an unauthenticated attack chain in the widely used mcp-atlassian project. Vicious Circle showed how a critical, maximum-severity vulnerability in CircleCI’s MCP server could turn local and agent-facing trust assumptions into a high-impact execution path. Across Pluto’s MCP research to date, the count stands at four confirmed CVEs, one of them at the maximum CVSS severity.
These vulnerability findings illustrate a broader visibility problem: security cannot patch, restrict, or monitor a server it does not know is running.
How to find and control shadow MCP servers
- Discover local and remote servers: Inventory should not be limited to cloud endpoints; local MCP servers can be especially easy to miss.
- Map exposed tools and capabilities: Undertake mapping, as a server that only reads public data has a different risk profile from one that can modify repositories or run commands.
- Assign ownership: Identify ownership and ensure every server has a team or person responsible for its configuration and updates.
- Check vulnerabilities and provenance: Review versions, maintainers, package sources, and known security findings.
- Restrict authentication and network exposure: Ensure a server does not become broadly reachable simply because a local development configuration was reused in a shared environment.
- Monitor changes: Perform regular monitoring, since tool definitions, permissions, and server versions can change after initial review.
Shadow MCP server vs. vulnerable MCP server
The two concepts overlap but should not be confused.
- A shadow MCP server is unknown or unmanaged. It may be perfectly patched and still create governance and visibility risk.
- A vulnerable MCP server has a technical security weakness. It may be fully approved and inventoried but still require remediation.
The highest-risk case is a server that is both shadow and vulnerable, because the organization is unlikely to know it needs action.
FAQs
1. Are local MCP servers safer than remote MCP servers?
Not automatically. Local servers reduce some network exposure, but they can have direct access to files, credentials, tools, and developer environments that make compromise or misuse highly consequential.
2. Is a shadow MCP server always unauthorized?
It is outside formal security oversight, but the user may have installed it for a legitimate business purpose. The security issue is the lack of inventory, review, and ownership.
3. How does shadow MCP relate to shadow AI?
Shadow MCP is a specific form of shadow AI. It describes unknown or unmanaged MCP infrastructure rather than the broader universe of unsanctioned AI applications and features.
4. What should security do first after finding a shadow MCP server?
Identify the owner, determine and understand what tools and data it can access, check its version and provenance, and decide whether it should be approved, restricted, updated, or removed.
5. How many MCP-related vulnerabilities has Pluto actually found?
Four confirmed CVEs against MCP servers to date, one of them at the maximum CVSS severity. See the MCPwnfluence and Vicious Circle entries for the specific findings.