If your team has spent 2026 wiring AI agents into internal tools, databases, and APIs, you've almost certainly touched the Model Context Protocol. MCP has become the default way to connect models to the outside world. This year it also became one of the most actively exploited pieces of AI infrastructure in production. Not hypothetically: confirmed CVEs, an NSA advisory, and at least one real supply-chain attack have already shipped.
I want to walk through what actually happened, because most of the coverage either overhypes it into a general "AI is scary" story or buries the practical detail under jargon. Neither helps a security team that has to decide what to do about the MCP servers already running in their environment.
The protocol shipped faster than the threat model
MCP, introduced by Anthropic as an open standard for connecting AI models to tools and data sources, solved a real problem: every agent integration used to be bespoke plumbing. MCP standardized it, and adoption followed accordingly. It's now embedded across coding assistants, internal copilots, and agent frameworks industry-wide.
Security did not keep pace. In May 2026, the NSA published its first formal guidance on the protocol, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, warning explicitly that MCP's rapid adoption has outpaced the security safeguards needed to run it safely. It names weak access controls, thin audit logging, and unsafe tool execution as the recurring gaps. It also flags several structural issues that are easy to miss if you're only thinking about MCP as "another API integration": agents that can autonomously invoke new tools at runtime, implicit trust between agents that never independently verify each other's output, and context windows that can leak or blend information across tasks that were never supposed to touch each other.
That's the theory. The practice arrived a month earlier.
A design flaw, not a bug in someone's code
On April 15, 2026, researchers at OX Security disclosed a systemic vulnerability in MCP's STDIO transport, the mechanism many MCP servers use to receive commands. The flaw passes configuration parameters straight to the host operating system's shell without sanitizing them, so an attacker who can influence that configuration can execute arbitrary commands on the host. It affects every officially supported SDK: Python, TypeScript, Java, and Rust. That's because it's a property of how the transport was designed, not a mistake in one implementation.
The scale is what makes this worth your attention rather than a footnote. OX Security's audit scanned more than 7,000 publicly accessible MCP servers and estimated roughly 200,000 vulnerable instances across a supply chain tied to over 150 million package downloads, per Infosecurity Magazine's reporting. Fourteen CVEs were assigned initially, with more than thirty related RCE issues surfacing in downstream products including LiteLLM, LangFlow, Flowise, Cursor, Windsurf, DocsGPT, and GPT Researcher. One of the resulting CVEs, CVE-2026-30623, affected LiteLLM's handling of MCP server configuration and required upgrading to a patched build. Anthropic's stated position, per the same reporting, is that STDIO's execution model is a secure default and that input sanitization is the implementing developer's responsibility. That's a defensible engineering stance, but it puts the burden of getting this right on every team that stands up an MCP server rather than on the protocol.
The attack that didn't need a CVE at all
The STDIO flaw is a transport-layer problem. A separate and arguably more relevant category of MCP risk doesn't require any vulnerability at all. It just requires a tool description an LLM is willing to trust.
This is called tool poisoning, and it already has a real-world example. In September 2025, security researchers at Koi identified a malicious npm package called postmark-mcp that presented itself as a legitimate connector for sending transactional email through Postmark. The find was reported by The Register and confirmed by Snyk. The package built credibility over fifteen published versions before version 1.0.16 quietly added one line of code: every outgoing email got blind-copied to an external address. Downloaded around 1,500 times a week, it ran silently inside developers' automation pipelines, exfiltrating invoices, password resets, and internal correspondence until it was caught.
No exploit, no injection, no CVE. Just a tool description an agent had no reason to distrust, sitting inside a workflow that already had legitimate permission to send email. OWASP's MCP Top 10 project lists this pattern, where the instructions hide in a tool's name, description, or schema rather than in user input, as one of the protocol's defining risks. It sits alongside confused-deputy scenarios, in which an MCP server acts with elevated privileges outside the user's actual context, and token passthrough, in which credentials issued for one system get forwarded to another that was never meant to receive them.
The bigger trend line
Zoom out and this fits a pattern the industry's own consensus data now confirms. OWASP's 2026 LLM Top 10, released in August and informed for the first time by a corpus of over 7,700 real incidents, shows Excessive Agency jumping from sixth place to third, the sharpest move in the list. Prompt Injection holds the top spot it's held since the list began. Read together, the message is consistent. The risk in agentic AI is increasingly not "can the model be tricked into saying something bad" but "what can the model do once it's tricked." And MCP is, structurally, the thing that expanded what models can do.
What this means if you're actually running MCP servers
So, a few concrete steps, in rough priority order. Audit every MCP server in your environment for STDIO transport usage and confirm you're on a patched SDK version. Treat MCP tool descriptions as untrusted input and scan them the same way you'd review a new dependency, not just at install time but on every update, since postmark-mcp earned trust before it broke it. Enforce least-privilege scoping so a compromised or poisoned tool can't reach further than the task actually requires. And log tool invocations with enough detail to reconstruct what an agent did and why, since the NSA guidance specifically flags weak auditability as a systemic gap.
None of this is exotic. It's the same discipline security teams already apply to third-party code and API integrations. It just hasn't fully arrived in the agentic AI world yet, largely because that world is moving fast enough that the tooling to test it hasn't caught up with the tooling to build it. That gap is exactly where we spend our time at RedLens, and it's why we track MCP-specific attack patterns as a distinct category in our own testing rather than treating agentic tool abuse as a subset of generic prompt injection. More on that in a future post. For now, if you're shipping MCP servers into production, the NSA guidance and the OX Security advisory linked above are worth reading in full before your next deployment, not after your next incident.