The Model Context Protocol shipped with security as an afterthought. Now there are roughly 7,000 MCP servers exposed on the open internet, half of them misconfigured. Anthropic's own reference implementation had remote code execution bugs in it. The reference SQLite server had raw SQL injection that got copy-pasted into thousands of production deployments. And OWASP just published a dedicated MCP Top 10 because the problem is that bad. Welcome to the new AppSec nightmare — where the "interpreter" is a language model, the "payload" is a conversation, and your AI agent just became the attack vector.
Every few years, the tech industry invents something that solves a massive developer experience problem and simultaneously creates a massive security problem. Docker containers. npm packages. Kubernetes configs. And now: the Model Context Protocol.
MCP, introduced by Anthropic in late 2024, is an open standard for connecting AI models to external tools, databases, APIs, and services. Think of it as a universal adapter that lets any AI agent talk to any data source through a standardized interface. Developers loved it because it killed the need for custom integrations. The ecosystem exploded. By early 2026, Gartner predicted that 75% of API gateway vendors and 50% of iPaaS vendors would have MCP features within the year. Up to 1,021 new MCP servers were being created in a single week at peak adoption.
The problem? MCP shipped security as a suggestion, not a requirement. And the industry learned the wrong lesson from every previous integration protocol: ship fast, secure later.
What MCP Is and Why It Matters
To understand why MCP is such an AppSec disaster, you need to understand what it actually does. In the pre-MCP world, if you wanted your AI agent to query a database, you'd build a RAG pipeline: convert data into a vector store, write custom integration logic, and pass relevant context into prompts. Every new data source meant another custom integration. It didn't scale.
MCP replaced all of that with a standardized JSON-RPC protocol. You put an MCP server in front of your database, your file system, your Git repo, your CRM, or anything else, and any MCP-compatible AI agent can just talk to it. No custom code. No per-integration plumbing. The agent requests data or invokes a tool through the MCP server, and the server handles the interaction with the underlying resource.
This is fundamentally different from a traditional API in one critical way: the thing deciding which API calls to make is a large language model. Not deterministic code. Not a human. A probabilistic model that can be manipulated through prompt injection, that hallucinates, and that makes decisions based on pattern matching rather than logic.
"Security teams might see MCP and think, 'It's just JSON-RPC over HTTP. Yet another API to protect.' That view is dangerous. The novelty is the decision engine: in traditional systems, component A talks to component B based on deterministic logic. In MCP architectures, an LLM is the router — probabilistic, manipulable, and prone to hallucinations that affect tool invocation." — CoSAI (Coalition for Secure AI) MCP Security White Paper, released January 27, 2026, via OASIS Open
That distinction changes everything. Your firewall can't inspect the semantic intent of a conversation. Your WAF can't detect when a prompt injection is tricking an agent into calling a destructive tool. Your RBAC policies assume a deterministic caller, not one that can be socially engineered through a chat message.
The Scale of the Problem
Researchers have found approximately 7,000 MCP servers publicly exposed on the internet, roughly half of the total deployed. Of those, 492 were identified as directly vulnerable to abuse due to missing authentication or encryption. According to Endor Labs' 2025 Dependency Management Report, which analyzed 2,614 MCP implementations, 82% use file system operations prone to path traversal (CWE-22), 67% use sensitive APIs related to code injection (CWE-94), and 34% use sensitive APIs related to command injection (CWE-78).
82% of MCP implementations use file system operations prone to Path Traversal (CWE-22). 67% use sensitive APIs related to Code Injection (CWE-94). 34% use sensitive APIs related to Command Injection (CWE-78). 7% tied to Cross-Site Scripting (CWE-79). 6% tied to SQL Injection (CWE-89). 5% tied to Open Redirect (CWE-601).
OWASP published a dedicated MCP Top 10 in 2025, separate from their existing API Security Top 10, because the threat model is different enough to warrant its own framework. The top risks include token mismanagement and secret exposure, excessive tool permissions, prompt injection through tool metadata, supply chain attacks through poisoned MCP packages, and shadow MCP servers deployed without IT oversight.
The CoSAI white paper, backed by Premier Sponsors including Google, IBM, Meta, Microsoft, NVIDIA, PayPal, and Zscaler, identified nearly 40 distinct threats across 12 categories. This isn't a handful of theoretical edge cases. This is a protocol-level security gap that the biggest names in tech are scrambling to address.
"As AI moves beyond chat models to agents, gaining the ability to take actions and interact with their environments and the real world through tool calling, the security implications and potential consequences are much more severe." — Ian Molloy (IBM) and Sarah Novotny, Co-Leads of CoSAI Workstream 4: Secure Design Patterns for Agentic Systems, January 27, 2026
When Anthropic's Own Code Gets Popped
If you want to understand how bad MCP security is, start with the fact that Anthropic — the company that created the protocol — shipped exploitable vulnerabilities in their own reference implementation. These aren't obscure third-party servers. This is the official code that developers are supposed to model their implementations after.
On January 20, 2026, security researcher Yarden Porat from Cyata published an exploit chain targeting Anthropic's Git MCP server (mcp-server-git) that achieved full remote code execution. The chain exploited three separate CVEs:
CVE-2025-68145 (CVSS 6.4): Path Validation Bypass. Admins can configure the MCP server to restrict operations to a specific repository path. The mechanism for enforcing that restriction simply didn't work. The server accepted paths outside the configured boundary without validation.
CVE-2025-68143 (CVSS 6.5): Unrestricted git_init. The git_init tool allowed users to create new Git repositories at arbitrary filesystem locations, turning any directory into a Git repository regardless of configured restrictions.
CVE-2025-68144 (CVSS 6.3): Argument Injection via git_diff. The git_diff command, which should be read-only, could be weaponized to empty or overwrite files by injecting arguments into the diff operation.
Individually, each bug looks manageable. Chained together with the Filesystem MCP server, they give an attacker full RCE on the host system.
"On its own, each MCP server was relatively safe. But when combined, the Git MCP server and the Filesystem MCP server cross interaction is what broke our assumptions. Hyperconnected AI agents and more MCP servers is a toxic combination that makes the agents fall." — Shahar Tal, CEO and co-founder of Cyata, speaking to Dark Reading (January 2026)
Cyata reported the findings to Anthropic in June 2025. It took six months for Anthropic to release the patched version (2025.12.18) in December 2025. And as Tal pointed out the obvious irony:
"If Anthropic gets it wrong — in their official MCP reference implementation for what 'good' should look like — then everyone can get MCP security wrong." — Shahar Tal, CEO of Cyata, speaking to Dark Reading (January 2026)
He's right. Reference implementations exist to show developers the correct way to build things. When the reference code itself is exploitable, every downstream implementation that copied its patterns inherits the same vulnerabilities.
Old Bugs, New Infrastructure
What makes MCP's security posture particularly frustrating is that most of the vulnerabilities aren't novel. They're the same classes of bugs that AppSec has been fighting for two decades, repackaged in AI infrastructure.
SQL Injection in the Reference SQLite Server
Anthropic's reference SQLite MCP server — a lightweight bridge between AI agents and structured data — concatenated user input directly into SQL statements without parameterization. Classic SQL injection, the kind that would fail a junior developer code review. But because it shipped as a reference implementation, thousands of downstream forks and production deployments inherited the vulnerability. Attackers could submit support tickets containing malicious SQL, which would be stored in the database and later executed by AI agents during triage — a stored prompt injection attack analogous to stored XSS.
Supply Chain Attacks via Typosquatting
Noma Security documented a particularly effective supply chain attack targeting Microsoft's Playwright MCP server (@playwright/mcp), one of the most popular MCP packages for web automation. Attackers published an unofficial package named playwright-mcp — a subtle but critical naming difference. That single typosquatted package hit 17,000 downloads in one week. When an organization deploys an untrusted MCP server, they're handing attackers direct access to their AI agent's execution environment and every system it connects to.
Default Credentials and Forgotten Endpoints
In 2025, security researchers investigating the McDonald's McHire platform (powered by Paradox.ai) found an administrator account secured with the credentials 123456:123456, no MFA, connected to a test restaurant account that should have been decommissioned years earlier. From that foothold, they discovered a Broken Object Level Authorization (BOLA) flaw in the API managing applicant data, where sequential IDs in requests allowed access to any applicant's personal information and chat logs. Legacy Stripe APIs were simultaneously being hijacked for card-skimming operations on at least 49 e-commerce sites through deprecated endpoints that were never decommissioned.
Multi-Tenant Access Control Failures
In May 2025, Asana released an MCP server allowing AI agents to interact with project management data across multiple tenants. Within a month, security researchers found a bug that could let users see data belonging to other users — a multi-tenant isolation failure that potentially affected up to 1,000 enterprise customers. Same month, Atlassian released an MCP server for Jira Service Management. Researchers from Cato Networks demonstrated that an attacker could submit a malicious support ticket through JSM containing a prompt injection that would be processed as a command by the AI agent.
The Attacks That Didn't Exist Before
While the classic vulnerability classes account for most MCP bugs, the protocol also introduces attack vectors that have no analogue in traditional AppSec.
Tool Poisoning
In a tool poisoning attack, malicious instructions are embedded in an MCP tool's metadata — its name, description, or parameter definitions. When an AI agent queries available tools, it reads these descriptions to decide which tools to invoke. Poisoned metadata can redirect the agent to execute a malicious function instead of the intended one, exfiltrate data through a side channel, or escalate privileges by chaining tool calls the developer never anticipated.
This is indirect prompt injection at the infrastructure layer. The attacker never interacts with the user. They compromise the tool definition, and every agent that connects to that MCP server becomes a victim.
MCP Preference Manipulation Attacks (MPMA)
A more subtle variant of tool poisoning, MPMAs alter how AI agents rank and select available tools. Instead of replacing a tool's function, the attacker adjusts metadata so that the agent preferentially selects a malicious tool over a legitimate one. In a multi-agent environment where dozens of tools are available, this kind of manipulation can go undetected for extended periods because the agent appears to be functioning normally — it's just consistently choosing the wrong tool.
Cross-Server Shadowing
When multiple MCP servers are connected to a single AI agent, a malicious server can "shadow" a legitimate one by registering a tool with the same name but different (malicious) behavior. The agent may invoke the shadowed tool without any indication that it's talking to the wrong server. Combined with the RCE chains demonstrated in the Anthropic Git/Filesystem server exploit, this means compromising one MCP server in a multi-server deployment can cascade into full environment compromise.
EchoLeak: Zero-Click AI Data Exfiltration
CVE-2025-32711, dubbed "EchoLeak" by Aim Security, demonstrated a zero-click vulnerability in Microsoft 365 Copilot that exploited design flaws in RAG-based AI systems. Attackers could automatically exfiltrate data from Copilot's context without requiring any specific user action. The primary chain combined three distinct vulnerabilities to achieve data theft from the AI's working memory. This class of attack — exploiting the junction between an AI agent and its tools — represents a new frontier that traditional security tools are blind to.
Just like employees spinning up unauthorized SaaS tools, developers are deploying MCP servers without IT oversight. These "Shadow MCP" instances bypass logging, auditing, and authentication entirely. OWASP's MCP Top 10 calls them out specifically, and the CoSAI white paper identifies them as one of the highest-risk deployment patterns in the agentic AI stack.
Real-World Incidents: It's Already Happening
In mid-2025, Supabase's Cursor agent — running with privileged service-role access — processed support tickets that included user-supplied input as commands. Attackers embedded SQL instructions in support ticket text that the agent executed against the database, exfiltrating sensitive integration tokens by leaking them into public support threads. Three factors combined to make this catastrophic: privileged access, untrusted input treated as commands, and an external communication channel for exfiltration.
WordPress MCP plugins exposed over 100,000 sites to privilege escalation. The Facebook API scraping incident of May 2025 saw attackers leverage weak user authentication to harvest data from 1.2 billion accounts. Intel's Hierarchy Management system exposed employee information through client-side encryption that was trivially decryptable, granting admin access to their internal system. In November 2025, OpenAI disclosed that their third-party analytics provider Mixpanel was breached, allowing attackers to export an analytics dataset.
None of these required zero-days. None required sophisticated exploitation. They were all the result of default credentials, missing authorization checks, unvalidated input, and forgotten endpoints — the same bugs we've been writing CVEs for since the early 2000s, now amplified by AI infrastructure that moves faster than security can follow.
"MCP is breaking everything." — Lori MacVittie, Distinguished Engineer and Chief Evangelist, F5 Networks Office of the CTO, speaking to CSO Online (2025)
Locking It Down: What Security Teams Need to Do Now
The CoSAI white paper, the OWASP MCP Top 10, and hard-won incident response lessons from 2025 all point to the same set of priorities. Here's what actually matters:
Inventory every MCP server in your environment. You cannot secure what you don't know exists. Shadow MCP is real and it's proliferating. Run discovery scans, audit developer tooling, and treat MCP server deployment as a change-management event that requires security review. If you're using third-party MCP servers from npm or PyPI, audit them before deployment. The typosquatting problem is active and ongoing.
Treat all LLM and MCP outputs as untrusted input. This is the single most important principle. Every tool argument generated by an AI agent, every response from an MCP server, every piece of data flowing through the pipeline should be validated and sanitized at every boundary where it's consumed. Parameterize SQL queries. Validate file paths using canonicalization. Escape special characters before passing data to shell commands. This isn't new advice, but it's being ignored at scale in MCP deployments.
Enforce least privilege on every MCP tool. Noma Security documented cases where AI agents tasked with cleaning duplicate customer records had database deletion permissions enabled by default, leading to thousands of legitimate accounts being destroyed. Default-permissive is the current norm. Flip it. Default-restrictive configurations, granular capability assessments, and regular permission audits should be standard.
Implement end-to-end identity chains. Every request should be traceable from end user through intermediate MCP servers to the final action. The CoSAI framework recommends token exchange (RFC 8693) rather than passing OAuth tokens directly, and emerging standards like SPIFFE/SPIRE for cryptographic workload identities. Don't trust localhost as an authentication boundary — even localhost-bound services need proper auth.
Evaluate server combinations for compound risk. The Cyata exploit chain required both the Git and Filesystem MCP servers to achieve RCE. Neither was catastrophic alone. Document which MCP servers run together in your environment and assess the combined attack surface. Individual risk assessments are insufficient when the real threat comes from cross-server interaction.
Deploy prompt injection detection at the MCP layer. Traditional WAFs and API gateways don't inspect for prompt injection payloads. Tools like Cisco's open-source MCP Scanner can help identify vulnerable configurations. The OWASP MCP Top 10 recommends strict schema validation on all tool inputs and outputs, with allowlists rather than blocklists.
# MCP Security Audit Checklist
# Run through these for every MCP server in your environment:
1. Authentication: Is auth enforced? (Not just "localhost = trusted")
2. Authorization: Are tool permissions default-restrictive?
3. Input validation: Are all tool arguments validated against schemas?
4. Path validation: Are file paths canonicalized before use?
5. SQL parameterization: Are queries parameterized, not concatenated?
6. Token management: Are secrets in env vars, not config files?
7. Network exposure: Is the server exposed to the internet?
8. Logging: Are all tool invocations logged with full context?
9. Supply chain: Is the package from the official source? (Check typos)
10. Cross-server risk: What other MCP servers share this environment?
11. Shadow MCP: Are there unauthorized MCP servers running?
12. Sandboxing: Is the server isolated via gVisor/Kata/containers?
Key Takeaways
- MCP security is today's most urgent AppSec problem: With 7,000 exposed servers, CVEs in the protocol creator's own reference code, and nearly 40 threat categories documented by CoSAI, MCP represents the fastest-growing attack surface in enterprise technology. If your organization is deploying AI agents, you almost certainly have MCP exposure whether you know it or not.
- Classic vulnerabilities are the primary threat: SQL injection, path traversal, command injection, BOLA, and missing authentication account for the vast majority of MCP security failures. Endor Labs found that 82% of MCP implementations are vulnerable to path traversal alone. The fix isn't exotic — it's the same secure coding practices AppSec has been preaching for 20 years, applied to a new context.
- Novel AI-specific attacks are escalating: Tool poisoning, preference manipulation, cross-server shadowing, and zero-click data exfiltration represent attack classes that traditional security tools can't detect. The LLM-as-router architecture means that prompt injection is now an infrastructure-level threat, not just a chatbot curiosity.
- Reference implementations set the security floor: When Anthropic's own code ships with RCE bugs that take six months to patch, every developer copying those patterns inherits the same weaknesses. The security of the entire MCP ecosystem depends on reference code being hardened, audited, and treated as production-grade from day one.
- Inventory and governance are non-negotiable: Shadow MCP is proliferating exactly like Shadow IT did a decade ago, except the blast radius is worse because MCP servers have direct access to AI agent execution environments. If you don't know what MCP servers are running in your environment, you don't have a security posture — you have a liability.
The MCP ecosystem is roughly where container security was in 2015 or npm security was in 2018 — adoption has massively outpaced security, and the industry is now scrambling to backfill controls that should have been there from the start. The CoSAI framework, the OWASP MCP Top 10, and tools like Cisco's MCP Scanner are steps in the right direction. But steps don't matter if your organization is still deploying MCP servers with default permissions, no authentication, and no inventory. The agents are already running. The question is whether you're securing them before or after you show up in someone's research paper.