MCP servers as a new attack surface: security and governance

Where MCP stands in October 2026

The Model Context Protocol is no longer a single-company project. On December 9, 2025, Anthropic handed it over to the newly founded Agentic AI Foundation under the Linux Foundation, which it co-founded with Block and OpenAI and which is backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. In the same announcement it cited more than 10,000 active public MCP servers and over 97 million SDK downloads per month.

Less than a year later the scale is different. According to the 2026-07-28 specification announcement, the Tier 1 SDKs are approaching half a billion downloads a month. MCP is supported by mainstream developer tools and chat clients alike, so the question for a company is not whether employees use it, but how many servers they have connected and who knows about them.

What the 2026-07-28 specification changed

From a security standpoint, these are the items in the changelog that matter:

• Stateless protocol. The initial handshake and the Mcp-Session-Id header are gone. The mandatory Mcp-Method and Mcp-Name headers let a gateway route and filter requests without parsing the body.
• Protection against authorization server mix-up. If the iss parameter (RFC 9207) is present in the response, the client must validate it before exchanging the authorization code for a token.
• Issuer-bound credentials. The client must not use them with a different authorization server.
• Dynamic Client Registration is deprecated. It is replaced by Client ID Metadata Documents; DCR remains for backward compatibility.
• Deprecated features. Roots, Sampling and Logging, as well as the old HTTP+SSE transport, are marked for removal, with a deprecation window of at least twelve months.

For companies with centralized identity management, the Enterprise-Managed Authorization extension, stable since June 18, 2026, matters more. Access to an MCP server is decided by the corporate identity provider, not by an individual user in an OAuth dialog. According to the announcement, it is so far supported by the Anthropic clients and Visual Studio Code, and by Okta on the identity provider side. If you use a different identity provider, you need to verify support yourself.

Four recurring risk classes

The OWASP MCP Top 10 project is still in beta, but its categories map well to what has actually happened. For decision-making, four groups are enough.

What actually happened: verified cases

Tool poisoning and the “rug pull” (April 2025)

On April 1, 2025, Invariant Labs showed that an innocent-looking add tool with hidden instructions in its description could make an agent in the Cursor editor send out the ~/.cursor/mcp.json file and SSH keys. They also described a variant in which the server changes the tool description only after the user has approved it.

GitHub MCP and leaks from private repositories (May 2025)

On May 26, 2025, the same authors demonstrated an attack where opening an issue in a public repository was all it took. An agent that read the issue followed the embedded instructions, pulled data from private repositories and published it in a pull request. The authors state explicitly that this is not a bug in the server’s code but an architectural problem at the agent level. So there is no patch; only restricting the token helps.

mcp-remote: CVE-2025-6514 (July 2025)

On July 9, 2025, JFrog disclosed a vulnerability in the mcp-remote proxy, versions 0.0.5 through 0.1.15. A malicious server returned a crafted authorization_endpoint address and, on Windows, achieved arbitrary command execution on the developer’s workstation. The fix shipped in version 0.1.16. Connecting to an untrusted server was enough.

postmark-mcp: the first documented malicious server (September 2025)

The postmark-mcp package on npm posed as the official integration. Version 1.0.16 of September 17, 2025 added a single line that sent a blind copy of every outgoing email to the attacker’s address. According to Koi Security, the package had 1,643 downloads. According to the article, it was otherwise a copy of the original library and the malicious line appeared only in this version, so a one-off review at adoption time would have found nothing.

Command execution via STDIO (April 2026)

On April 15, 2026, OX Security described a systemic problem: applications that let a user enter an MCP server configuration with the STDIO transport often thereby allow arbitrary command execution. Affected products included LiteLLM, Flowise, Windsurf and LangFlow. The Register reports the researchers’ figures – up to 200,000 vulnerable servers, 150 million downloads of affected packages, ten CVEs of high or critical severity, and successful poisoning of nine out of eleven MCP marketplaces tested. According to the same article, Anthropic declined to change the architecture, saying this is expected behavior.

The figures come from the researchers themselves and are best read as an upper-bound estimate. The dispute over whether the flaw lies in the protocol or in the applications built on it does not change the practical conclusion: an MCP server configuration is executable input and must be treated as such.

Deadbugz (August 2026)

On August 12, 2026, Pillar Security described a campaign in which a single account opened 23 pull requests against unrelated projects within 74 minutes on August 10. Seventeen of them added a remote server to the MCP configuration, and four more ran a hidden local script. The server offered two harmless tools – text formatting and summarization. After three calls, the server changed the instructions it returned and steered the agent toward searching for SSH keys, AWS credentials, shell history and Kubernetes configuration.

What the specification solves and what it does not

The official Security Best Practices are a good basis for assessing servers. A server must not accept a token that was not issued explicitly for it, and must not pass it on (token passthrough). A client that offers one-click installation of a local server must display the exact, untruncated command before running it, and must not open the authorization URL via a shell – a direct response to bugs like CVE-2025-6514. The document also recommends incremental scope expansion instead of a single broad token.

But the specification defines how the parties communicate. It does not say whether a server is trustworthy, and it cannot prevent the model from obeying an instruction hidden in data. The tool poisoning and prompt injection categories remain the operator’s responsibility.

Governance: six controls in the order they make sense

1. Inventory

In a research note dated May 4, 2026, the Cloud Security Alliance recommends, as an immediate step, an inventory of all MCP servers in the organization, including those that came bundled with developer tools. Sources are configuration files on workstations, .mcp.json files in repositories and client telemetry.

2. A client-enforced allowlist

A list of approved servers on a wiki stops nobody. Enforcement has to live in the tool and must not be bypassable by renaming. This is where products differ, so you need to read the documentation, not just the feature name.

The GitHub Copilot documentation states that the “Registry only” mode compares only the server name or ID, which can be bypassed by editing the configuration file, and for stricter enforcement points to the URL-based enterprise allowlist. The Claude Code documentation says the same about serverName entries: they are not a security control, and enforcement has to be done by URL or exact command. An example managed configuration for this tool:

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverUrl": "https://*.internal.example.com/*" },
    { "serverCommand": ["/usr/local/bin/company-mcp-server"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

According to the documentation, without the allowManagedMcpServersOnly switch the allowlists from all levels are merged and users can extend the list themselves. Look for a similar detail in every client running in your company.

3. Review like dependencies – and continuously

Adding a server to the allowlist should go through the same process as a new library: who the author is, where it is installed from, what permissions it has. Pin the version and pull packages through an internal mirror where they can be scanned. The postmark-mcp case shows that malicious code may only appear in a later version, so the check has to run on every update. The approach is the same as for dependency scanning.

In addition, track changes to tool definitions. Pillar Security recommends treating a description change on an already approved server as a security event.

4. Least-privilege tokens

• No personal tokens with full access. For the GitHub server, a fine-grained token limited to specific repositories; for a database, a read-only account.
• Separate contexts. An agent that reads untrusted input (public issues, incoming emails) should not, in the same session, have access to sensitive data and an outbound channel at the same time.
• Tokens do not belong in shared configuration files. Where possible, use per-user OAuth or central authorization through the identity provider.

5. Isolating local servers

By default, a local server runs with the user’s privileges, meaning access to ~/.ssh, ~/.aws and the kubeconfig. The CSA recommends running MCP server processes in containers or a sandbox without access to the host’s credentials; the specification recommends the same to clients. Restrict outbound network access too – exfiltration needs a way out. The principles are the same as for general container security.

6. Logging tool calls

Without a record of which agent called which tool with which arguments, an incident cannot be investigated. The 2026-07-28 specification documents OpenTelemetry trace context propagation, and Claude Code can record server and tool names when export is enabled. The logs belong in the same system as your other security events; see monitoring and logging.

When a strict regime is overkill and where it falls short

A complete MCP ban is a legitimate choice for environments with regulated data, but it has a cost: people find workarounds through unmanaged tools and visibility gets worse. An approved catalog with a fast onboarding process tends to be more sustainable than a ban.

A small team with a handful of servers from major vendors does not need its own registry or gateway. An enforced URL-based allowlist, narrow tokens and a review rule for configuration files are enough. A central MCP gateway only makes sense with dozens of servers and multiple clients; it is yet another component that holds tokens and must itself be secured.

None of these controls reliably solves prompt injection. An allowlist does not help when an approved server returns data with an embedded instruction – which is exactly what happened with GitHub MCP. For actions with irreversible impact (writes to production, sending data out, deletion), keep a human confirmation step and assume the agent can be manipulated.

What to do on Monday

Key takeaways

• An MCP server is a dependency that talks to the model. Besides code, it supplies text the agent takes as instructions, and it can change that text at any time.
• The incidents are documented, not hypothetical. Tool poisoning, the GitHub MCP leak, CVE-2025-6514, postmark-mcp, the STDIO configuration problem and Deadbugz all have public primary sources.
• The 2026-07-28 specification improved authorization, but it does not and cannot solve server trustworthiness or prompt injection.
• A name-based allowlist is not a control. Vendors say so themselves in their documentation; enforce by URL or exact command.
• Narrow tokens and context separation have the biggest effect. They limit the damage even when the other layers fail.
• A change to the MCP configuration in a repository is a change to executable code and belongs under mandatory review.