01Registry and supply chain risks
MCP-Servers are predominantly built by independent developers and distributed via unofficial registries; an official registry is planned, according to Wiz, but not yet available. As a result, the familiar patterns of package ecosystems apply: typosquatting, impersonation, Rug Pulls, and account takeovers. Labels such as “official” or “verified” confirm neither the developer's identity nor a demonstrable connection to the named product — Wiz further reports that around 100 of roughly 3,500 servers listed in one examined registry pointed to non-existent repositories.
02Client-side risks and auto-run
Many MCP-Clients execute tools automatically (auto-run); this implicitly trusts Tool responses and increases the impact radius of a compromised server — explicitly contrary to the MCP specification, according to Wiz. In addition, there are Tool naming conflicts in which deliberately identically named tools override legitimate functions, the hijacking of overlapping slash commands such as /deploy or /scan, as well as indirect Prompt Injection via untrusted content, for example from a README or a commit message. Existing client guardrails are, according to Wiz, inconsistent and were not developed with MCP security in mind.
03Substantiated incidents and CVEs
Documented cases include access via the GitHub MCP-Server to private repositories and their publication, as well as the exfiltration of WhatsApp messages by a malicious MCP-Server that switched to harmful behavior only after the second use (both described by Invariant Labs, cited in the NSA guide). A vulnerability with an identifier is CVE-2025-49596 in the MCP Inspector: a Remote Code Execution rated as critical via unchecked inputs, fixed in version 0.14.1 according to the NSA. Wiz also describes its own proof of concept (Gal Nagli) in which an MCP-Server for parsing GitHub documentation led to Remote Code Execution on the MCP-Host.
04Detection and monitoring
The NSA guide recommends regularly scanning networks for open, unauthorized, or vulnerable MCP-Servers — also because these can change their ports dynamically, which makes differential scan reports valuable; tools mentioned include MCP Scanner, Ramparts, CyberMCP, and Proximity. All Tool and model calls should be logged with parameters and identities and integrated into the existing monitoring (such as a SIEM) in order to detect suspicious call patterns. In addition, a formal process for tracking MCP-related vulnerabilities via CVEs and advisories, along with a maintained inventory of the servers in use, is part of this.
05MCP-Gateway and Allowlisting
Wiz recommends centralizing MCP-Server usage through a proxy or an MCP-Gateway in order to create a single control point for audit logging, monitoring, guardrails, and governance. In addition, binary and server allowlisting on the MCP-Host helps to restrict the execution of unknown servers, as does Sandboxing via containerization, egress control, and syscall filters — although Wiz stresses that this does not prevent the attack from being passed on to other servers and tools. The NSA additionally names filtering egress proxies (such as Squid or tinyproxy) or DLP solutions, as well as OS Sandboxing with seccomp, AppArmor, SELinux, or AppContainer.
06What we check in the assessment
We inventory the MCP-Servers and -Clients in use, examine the provenance and trust signals of the registries used, and assess permissions, token scopes, and auto-run behavior against the Least Privilege principle. This includes network scans for open or unauthorized MCP-Servers, the review of Sandboxing, gateway, and allowlisting, as well as the integration with logging and SIEM. On this basis we provide a prioritized list of measures; for deeper engagement we offer consulting, technical assessments, penetration tests, and awareness formats such as webinars.
