MCP Security: Real Incidents, Risks, and Mitigation Strategies

Model Context Protocol (MCP) gives AI agents a standardized way to interact with external tools, databases, APIs, files, and services.

That connectivity is also where much of its security risk sits.

Since 2025, researchers have documented MCP-related attacks ranging from indirect prompt injection and data exfiltration to local code execution and malicious package distribution.

Two vulnerabilities received critical CVEs:

→ CVE-2025-49596 in MCP Inspector

→ CVE-2025-6514 in mcp-remote.

Other incidents exposed architectural weaknesses around excessive permissions, tool trust, and software supply chains.

So, where does an MCP attack cross from untrusted input into privileged execution?

1. Prompt Injection Can Become Data Exfiltration

One of the earliest documented MCP attack paths involved GitHub.

In May 2025, Invariant Labs demonstrated how a malicious GitHub issue could contain hidden instructions that were processed by an agent using GitHub’s MCP server. The agent had access to private repositories. The injected instructions caused it to retrieve private information and place that information into a public pull request.

The technical problem was the trust boundary:

Public issue → MCP server → agent context → private repository access → public GitHub action

The MCP server performed its intended operations. The failure occurred because the agent treated attacker-controlled issue content as an instruction with authority comparable to the user’s original request.

This is effectively a confused-deputy problem. The agent possessed privileges that the attacker did not, and prompt injection caused the agent to exercise those privileges on the attacker’s behalf.

Granular permissions are therefore critical. An agent processing public GitHub content should not automatically inherit unrestricted access to private repositories.

2. Excessive MCP Permissions Can Turn Prompt Injection into Credential Theft

A similar pattern appeared in a Supabase and Cursor incident.

An attacker placed instructions inside a support ticket. Cursor’s agent, connected to Supabase MCP, had access to a service_role credential. The injected instructions caused the agent to query the integration_tokens table and return sensitive tokens through the same attacker-controlled ticket.

The attack combined three conditions:

Untrusted input + privileged data access + attacker-controlled output

That combination is sometimes described as the agentic “lethal trifecta.”

The MCP connection itself did not need to be compromised. The attacker manipulated the model’s interpretation of content while the agent already had excessive database privileges.

A safer architecture would use scoped database credentials, row-level security, read-only access where possible, and explicit controls over which data can leave the agent’s trust boundary.

3. MCP Tooling Itself Can Introduce Remote Code Execution

CVE-2025-49596 demonstrates a different class of problem.

MCP Inspector’s local proxy previously exposed functionality without sufficient authentication. A malicious webpage could interact with the local proxy and ultimately trigger MCP commands on the developer’s machine. The vulnerability was rated CVSS 9.4 and fixed in MCP Inspector 0.14.1.

This matters because localhost is often treated as inherently trusted.

It isn’t.

A local development service exposed through a browser can become an attack surface when origin validation, authentication, and network binding are weak.

The mitigation is therefore architectural as well as procedural: update vulnerable versions, require authentication for local control surfaces, validate browser origins, and avoid exposing development proxies beyond the interfaces that actually require access.

4. A Remote MCP Server Can Reach the Host OS

CVE-2025-6514 exposed an even deeper trust failure in mcp-remote.

The vulnerable versions accepted an attacker-controlled authorization_endpoint during the OAuth flow. A malicious MCP server could provide a crafted value that reached Node’s open() handling and ultimately resulted in arbitrary OS command execution. Versions from 0.0.5 through 0.1.15 were affected; 0.1.16 contained the fix. The vulnerability received a CVSS 9.6 rating.

The attack path is particularly important:

Untrusted MCP server → malicious OAuth response → client-side URL handling → OS command execution

The vulnerable component was a client-side bridge, but the input originated from the remote MCP server.

That means validating server-supplied values must happen before those values reach operating-system primitives.

5. MCP Supply Chains Create Another Attack Surface

Security failures also appeared before an MCP server even reached the agent.

In September 2025, a malicious npm package impersonating postmark-mcp added a hidden BCC address to outgoing emails. Every email sent through the package could therefore be copied to an attacker-controlled address.

The dangerous part was the simplicity of the modification: the package could perform its advertised function while silently executing an additional action.

A separate 2026 incident involved a fake Oura Ring MCP server distributed through the software supply chain. The package contained an obfuscated loader associated with the StealC infostealer and targeted saved credentials, tokens, SSH keys, and cryptocurrency wallet data.

This makes package provenance an MCP security control, not merely a software-development hygiene issue.

How to Mitigate MCP Security Risks?

MCP security needs controls at several layers: