Critical MCP Vulnerabilities are Slipping Through the Cracks
MCP’s widespread traction among GenAI developers is well-deserved. The Model Context Protocol offers GenAI systems a seamless way to connect tools, models and agents in real time. This allows them to build and adapt workflows on the fly, often without human involvement. And it opens the door to many other powerful new capabilities. But it also introduces new points of failure that traditional architectures were never designed to handle.
Much of the security talk around GenAI still focuses on prompt injection, for good reason. It’s easy to understand, easy to demonstrate, and it targets the part of the system everyone sees: The model. But in MCP-based environments, the real risks often run deeper. And these are risks that most security teams still aren’t looking for. In this article, we’ll take a closer look at four vulnerabilities that tend to slip through the cracks. Each one can result in significant damage – yet most fall outside the scope of traditional security controls.
1. Supply Chain Vulnerabilities: A Dangerous Backdoor
A commonly overlooked fact is that the local MCP server is itself just a package. Like any other installed via tools like npx, pip or or other public registries, it can execute code during the installation process.
This means an attacker doesn’t need to wait for an MCP client to trigger a hijacked tool, poison its context, or manipulate the agent. They can simply publish a malicious MCP server package with code execution built into its install script. Alternatively, the package can load additional malicious dependencies during installation to remain stealthy and extend its reach.
If this rogue version is installed, it can immediately run arbitrary code as part of the setup process. Once installed, most environments treat packages as trusted. That means a compromised MCP server package could gain broad access to execute code, read or modify sensitive data, or establish deeper persistence. Without validation or integrity checks, the attacker’s package may blend in seamlessly until it doesn’t.
2. Tool Name Spoofing: Trusting the Wrong Tool
In many MCP setups, tools are discovered and invoked based on their names, function signatures and descriptions. This opens the door to Tool Name Spoofing – a technique where an attacker registers a fake MCP server that includes a malicious tool using the same name, signature, or description as a legitimate tool from another MCP server.
When the agent decides what to run based primarily on these identifiers, it doesn’t take much to mislead it. An attacker can register an MCP with a fake tool that looks identical on the surface, for example, a spoofed version of “code-review” that mimics the real “code_reviewer” in name, interface and behavior.
Once spoofed tools are in the system, they can be difficult to detect. They might silently observe how other tools operate, intercept inputs, or deliver slightly altered outputs that compromise downstream results. And because they blend in with what the system expects, they often operate without raising alarms.
3. Single Point of Privilege: A Chain of Trust Becomes a Chain of Risk
In typical MCP architectures, the MCP client is granted access to a wide range of tools and services. It authenticates on behalf of the user and is authorized to perform actions across those systems. This central access model is efficient, but it also creates a critical weakness as the agent becomes a single point of privilege.
This means that if any MCP server in the toolchain is compromised or malicious, it can exploit the agent’s trust to carry out actions across other services. The server doesn’t need direct access to those services; it just needs to manipulate the agent into making the requests on its behalf.
For example, a malicious MCP server can return crafted responses that cause the agent to call external APIs, write to sensitive data stores, or initiate other high-privilege operations, all under valid authentication and often within the expected flow. The agent thinks it’s following instructions from a tool but in reality, it’s being used as a proxy to expand the attacker’s control.
This abuse doesn’t require lateral movement or privilege escalation in the traditional sense. It simply leverages the privileges the agent already holds and the trust it places in every tool it calls.
4. Context Bleeding: When Memory Crosses the Line
In MCP workflows, the client (typically an agent) interacts with multiple tools over the course of a single session or conversation. These tools share a common context—often used to pass useful information, track history, or coordinate complex tasks. But this shared memory model comes with a hidden risk: Context Bleeding.
This is how it happens: the agent calls a tool, which handles an authentication task and stores sensitive data (e.g. access tokens, secrets, or PII) within the session context for later use. Later in that session, the agent calls a second tool, which now has access to the same context, including data it was never intended to see.
If this second tool is malicious, it can intentionally read and exfiltrate that sensitive data. But even if it’s not malicious, it might accidentally log or leak the information, simply because it wasn’t designed with strict context boundaries in mind.
This risk grows as the number of tools and their level of access increase. Without proper isolation or redaction mechanisms, one tool’s output becomes another tool’s input by design or by accident. The more shared states that an agent maintains, the greater the chance that sensitive information leaks into the wrong hands.
The Bottom Line: GenAI Needs Protocol-Level Defenses
The biggest risks in GenAI systems aren’t the ones that are grabbing headlines. They’re the quiet ones – the misplaced trust, the shared memory that lingers too long, the tool that looks just close enough to be legitimate. These things don’t break the system outright. They slip through it.
MCP is powerful, but it rewrites how risk works. Old security solutions don’t catch what happens when agents call each other freely, or when context sticks around longer than it should. And most teams aren’t focusing on that level of detail yet.
That needs to change. It’s not enough to audit the model or scan the output. We must pay attention to what holds everything together – the glue, not just the surface. That’s where the real MCP vulnerabilities are hiding.
