Understanding the MCP Architecture

To understand the vulnerabilities, first understand what MCP does.

MCP establishes a standardized way for applications (called MCP Hosts) to communicate with backend services (called MCP Servers). An IDE might be an MCP Host. A local file system service might be an MCP Server. The MCP Client handles the protocol details between them.

The architecture sounds clean. Standardized interfaces. Clear separation of concerns. But the implementation details reveal significant security gaps.

• No authentication by default. The protocol provides minimal guidance on authentication. MCP servers typically implement weak or no authentication mechanisms. Applications connecting to MCP servers often trust all connections.

• Session IDs exposed in URLs. The protocol specification mandates session identifiers in URLs like /messages/?sessionId=UUID. This violates fundamental security practice. Session IDs in URLs get logged in server access logs, browser history, and proxy caches. An attacker who sees a session ID in a log can hijack that session.

• No message integrity controls. The protocol lacks mechanisms to verify that messages haven't been tampered with. No message signing. No integrity checks. An attacker positioned between an MCP Host and MCP Server could modify messages in transit.

• Protocol designed for functionality, not security. Developers built MCP to enable integrations. Security considerations came later, if at all. The fundamental architecture makes it difficult to add security without breaking compatibility.

These aren't implementation bugs. They're design flaws baked into the specification itself. That matters because it means patching individual servers doesn't solve the underlying problem.

The Vulnerability Landscape

Security researchers at Equixly conducted assessments of popular MCP server implementations and documented a troubling pattern.

• Command Injection: 43% of implementations. MCP servers typically expose tools that take user inputs. A file search tool accepts search terms. A database query tool accepts SQL parameters. A code execution tool accepts commands. If these inputs aren't properly sanitized, attackers can inject shell commands.

Consider a simplified example. An MCP server exposes a "search files" tool that takes a filename parameter and runs a shell command like grep -r "filename" /data. If an attacker can control the filename parameter and inject shell metacharacters like ; rm -rf /, the server executes arbitrary commands with the permissions of the process running the MCP server.

• Path Traversal: 22% of implementations. File access tools that don't properly validate paths allow reading files outside intended directories. An attacker requests ../../etc/passwd or navigates to sensitive configuration files containing API keys and credentials.

• Server-Side Request Forgery (SSRF): 30% of implementations. Tools that fetch URLs don't validate where those URLs point. An attacker can craft a request to an internal service only accessible from the developer's machine. Access internal dashboards. Exfiltrate data from internal tools. Interact with cloud metadata services available only to that machine.

• Other issues: 5%. Rate limiting, denial of service, and permission bypass issues.

These vulnerabilities matter because MCP servers run on the same machines where developers work. A compromised MCP server can allow an attacker to gain a foothold on the developer's workstation.

The Vendor Response Problem

When Equixly disclosed vulnerabilities to development teams, responses varied dramatically:

• 30% acknowledged and released fixes. These teams took the issue seriously, patched their servers, and released updates.

• 45% claimed the risks were theoretical or acceptable. This response is troubling. The argument goes: "If someone can send arbitrary input to my MCP server, they'd need to know the server exists and how to interact with it. That's not a real risk." This dismisses a fundamental threat model. Attackers don't need to discover servers. They can target them systematically. They can guess common server names. They can see what's running on internal networks. More importantly, the MCP server might be exposed beyond the developer's machine through misconfigured proxies, cloud deployments, or shared infrastructure.

• 25% didn't respond. These teams either didn't prioritize security disclosures or didn't have processes for handling them.

Only a quarter of teams actually fixed the vulnerabilities. For an ecosystem built on standardization and trust, that's a significant problem.

The Expanded Attack Surface

A subtle but important distinction: MCP servers can be called by anyone, not just AI applications.

When Claude Desktop or another legitimate AI application calls an MCP server, the user can see what the application intends to do. Claude shows reasoning. It explains its steps. There's transparency.

An attacker has no such constraint. They can directly call MCP server tools with malicious inputs. They don't ask permission. They don't explain their actions. They just exploit the vulnerability.

This creates an attack surface developers often don't account for. They build MCP servers thinking "an AI application will call this." But the protocol doesn't restrict callers. In a network environment, any client that knows the server exists can interact with it.

For local development scenarios, this might be a single developer's machine. For deployed scenarios (and increasingly, organizations are deploying MCP servers in shared environments, containers, and cloud), the attack surface expands dramatically.

Why This Matters: The Standardization Trap

Standardization normally improves security. Well-established standards have security built in. HTTPS has security considerations embedded in the spec. OAuth has threat modeling. REST API best practices are documented and mature.

MCP is young. It was designed for functionality first. Security considerations are afterthoughts. But because it's standardized, the same vulnerabilities appear across implementations. This is particularly dangerous because MCP aims to become ubiquitous infrastructure. As more tools integrate with it, as more developers build servers for it, as it becomes embedded in more workflows, the vulnerabilities become systemic.

The protocol also creates a false sense of security through standardization. Developers assume that because MCP is standardized, it must be secure. They build MCP servers without the same rigor they'd apply to a public-facing API. They don't implement the security patterns they'd use elsewhere.

Fixing the Wrong Problem

There's discussion about adding layers of abstraction around MCP. Wrappers that generate MCP servers automatically from API specifications. Tools that make implementation easier.

But adding abstraction layers doesn't fix the underlying problem. If the MCP specification has fundamental security flaws, building generators on top of it just creates more vulnerable servers faster.

The real issue is that MCP was designed for functionality, not security. Session IDs in URLs. No authentication by default. No message integrity. These aren't bugs that can be patched in implementations. They're architectural decisions that affect the entire protocol.

Before the industry adds more abstraction, it needs to address these fundamentals. Redesign the specification to include security. Establish authentication standards. Move session IDs out of URLs. Require message integrity verification. Provide clear security guidance for implementers.

The comparison to REST APIs is instructive. REST APIs have decades of security evolution. Best practices are documented. Testing frameworks exist. The ecosystem matured through hard lessons learned. MCP is in that early phase where vulnerabilities are common, but the response from vendors and the community isn't yet treating them with appropriate urgency.

What This Reveals About AI Infrastructure

The MCP vulnerability pattern reveals something broader about how AI infrastructure is being built. The rush to enable AI capabilities is outpacing security fundamentals.

Developers want to connect AI to their tools and data quickly. Standards like MCP promise to make that easier. But that speed creates shortcuts. Security gets deferred. The focus is on "does it work," not "is it secure."

This happened with cloud infrastructure. Early cloud deployments had widespread misconfiguration because developers weren't familiar with cloud security models. It happened with APIs, where CORS, authentication, and authorization were afterthoughts. It's happening with MCP.

The pattern repeats because the incentives are misaligned. A developer who ships quickly with a vulnerable MCP server faces no immediate consequences. Users might see benefits immediately. The security incident comes later. By then, the developer has moved on to the next project.

How Organizations can Tackle MCP Risks

Organizations deploying AI infrastructure need to break the vicious cycle of security risks embedded in emerging standards. They need to:

• Audit MCP server implementations before deployment. Don't assume standardization means security. Review the code. Test for common vulnerabilities. Validate that security controls are actually implemented.

• Implement network isolation. MCP servers shouldn't be exposed directly to untrusted networks. Use VPNs, firewalls, and segmentation to restrict access. Assume they will be compromised and design accordingly.

• Monitor MCP server activity continuously. Track what tools are being called. What inputs are being provided. What outputs are being returned. Unusual patterns indicate exploitation attempts.

• Rotate credentials and audit logs regularly. If an MCP server stores API keys or credentials, rotate them frequently. Monitor access logs for signs of unauthorized use.

• Maintain an inventory of MCP servers. Know what MCP servers are running in your environment. What do they expose? Who has access? This inventory becomes the foundation for security management.

As organizations scale their AI infrastructure, as they deploy more MCP servers, as these servers become critical pathways for AI-to-tool integration, visibility and control over MCP activity becomes essential.

The question for organizations building with MCP isn't whether vulnerabilities will exist in their MCP servers. The research shows that vulnerabilities are systemic across the ecosystem. The question is whether they'll detect and prevent exploitation before damage occurs.