MCP Security Through the Lens of CVE Data and Breach Analysis
Arve Kjoelen, the former CISO at McAfee, has published a new analysis that takes a hard look at the security reality of the Model Context Protocol. Arve digs into 99 MCP-related CVEs published in 2025, where the data shows that MCP vulnerabilities skew more severe than vulnerabilities in non-AI software and even AI software overall. He also finds that roughly 60 percent of MCP CVEs stem from command injection weaknesses, primarily CWE-77 and CWE-78.
That data aligns closely with what we are seeing in real-world breach reports. Incidents involving projects like mcp-remote and even Figma reflect the same concentration of command injection flaws. Where Arve’s research breaks new ground is in clearly quantifying the code-level risk created by MCP’s design. Where breach data adds context is in showing how attackers are already evolving beyond what CVEs capture.
In practice, attackers rarely stop at command injection. They layer it with prompt injection, tool poisoning, and other AI-native techniques that the CVE system does not describe well. CVEs tell us where code breaks. Breach timelines show how systems fail when architectural trust assumptions are exploited. Many of the largest MCP-related breaches over the past year, including incidents involving GitHub, WhatsApp, Supabase, and Atlassian, were not driven by classic code vulnerabilities at all. The systems operated as designed. The problem was that they were designed without accounting for the fact that LLMs cannot reliably distinguish trusted instructions from poisoned data.
The command injection concentration itself is not surprising. What is new is the widening gap between how vulnerabilities are cataloged and how attacks actually unfold. One known but consistently ignored issue shows up in nearly every major incident is least privilege, where over-scoped permissions turned otherwise containable weaknesses into enterprise-wide failures.
Rethinking trust, visibility, and control in agentic systems
From a defensive standpoint, the most important assumption to revisit is whether MCP is already in your environment. In our work, we routinely find MCP servers running on developer laptops inside some of the most heavily regulated organizations in the world. The question is no longer whether to allow MCP. It is whether you have visibility into what is connected, what it can do, and how it is being used.
CISOs who position themselves as blockers tend to get routed around. The stronger move is to take this conversation to the board proactively. MCP and agentic AI can deliver real efficiency gains. Boards want that upside. Security leaders who can say “here’s how we enable it safely” become strategic partners rather than gatekeepers.
That starts with discovery. Run it on endpoints, because that is where MCP lives today. Build policy from observed behavior, not assumptions. Enforce least privilege, require logging, and restrict sensitive operations based on real usage patterns. Stop assuming vetted sources are safe. One of the most visible MCP breaches involved an official GitHub MCP server. Stop treating this as a cloud-only problem and stop issuing broad-scope tokens to agents.
This is exactly the gap Helmet was built to address. By providing MCP-specific discovery, monitoring, and policy enforcement, Helmet lets organizations move fast with agentic AI without inheriting unnecessary risk.