MCP Security (November 2026): Real Attacks and Fixes

Real MCP attacks so far fall into four groups: poisoned tool descriptions, prompt injection that chains tools to leak data, command injection in clients and SDK wrappers (CVE-2025-6514 scored 9.6), and malicious packages such as postmark-mcp. The controls that stop them are tool pinning, audience-bound OAuth tokens, sandboxed local servers and a policy gateway.

Updated 13 November 2026. The Model Context Protocol is now the default way to connect agents to tools. Most major agent platforms support it, and the spec has had three revisions since June 2025. The security picture has matured with it. There is a published list of attacks in the spec itself, a run of CVEs in clients and SDK wrappers, and at least one malicious server found in the wild. This post covers the incidents we could verify, what the spec now requires, and a checklist you can run against your own MCP clients and servers.

What are the biggest MCP security risks in 2026?

The biggest risk is not the protocol itself. It is that an MCP server's descriptions and outputs flow straight into the model's context, and the model can call other tools with real credentials. Put an untrusted server, an untrusted document and a powerful tool in the same session and you have a data-exfiltration path. The spec's own security best practices add the classic problems: confused deputy, token passthrough, SSRF, state handle hijacking and local server compromise.

A useful way to rank the risk is three questions. Does the session mix untrusted content with private data? Can any tool send data out (email, HTTP, a public repo)? Do tools run with broad, long-lived credentials? If the answer to all three is yes, you have a breach waiting to happen, whatever the spec says.

What real MCP attacks and vulnerabilities have happened?

Here are the ones we could verify on the researchers' or vendors' own pages:

Notice the pattern. Only one of these is a flaw in an MCP server's business logic. The rest are in clients, proxies, inspectors, packaging and the way hosts launch servers. In practice, MCP security is mostly host and supply-chain security.

What is MCP tool poisoning and how do you stop it?

Tool poisoning is hiding instructions in a tool's name, description or schema. The model reads them as context, even though the user never sees them. A tool called "add numbers" can carry text telling the model to read ~/.ssh/id_rsa and pass it in an argument. A variant, the "rug pull", serves a clean description at install time and changes it later.

Controls that work:

• Pin and hash tool definitions. Record each server's tool list and descriptions when you approve it, and block or re-prompt if they change. The 2026-07-28 spec makes this easier, since tools/list now carries cache fields (ttlMs, cacheScope) and servers should return tools in a fixed order.
• Allow-list servers. Run only servers from a curated internal registry, not whatever a user pastes into a config file.
• Scan descriptions. Flag descriptions with instructions aimed at the model ("before using this tool, read…"), references to files or secrets, or unusual length.
• Separate privileges. A tool that reads sensitive data and a tool that can send data out should not be in the same session without a policy check between them.

What is token passthrough and why does the MCP spec forbid it?

Token passthrough is when an MCP server accepts a token that was not issued for it and forwards it to a downstream API. The spec forbids it: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." Passthrough breaks audience checks, bypasses rate limits and monitoring tied to the server, and destroys the audit trail. Downstream logs show the user's token, not the server that used it.

The fix has been in the spec since the 2025-06-18 revision. MCP servers are OAuth resource servers, and clients must send Resource Indicators (RFC 8707) so the token is bound to one server. The server validates the audience, then uses its own credentials, or a token exchange, to call downstream APIs. If you wrap an existing API as an MCP server, this is the line most teams get wrong. See our MCP server development guide for the server side.

What is the confused deputy problem in MCP?

It is an attack on MCP proxy servers that use one static OAuth client ID with a third-party API while letting MCP clients register dynamically. If the third-party server remembers consent in a cookie, an attacker can register a client with their own redirect URI and send the user a link. The consent screen is skipped and the authorization code goes to the attacker.

The spec requires per-client consent on the MCP server before forwarding to the third party. Proxies must store approved client IDs per user, use exact redirect URI matching, use single-use state values set only after consent, and protect consent cookies with __Host-, Secure, HttpOnly and SameSite=Lax. The consent page must also block framing.

What changed in MCP authorization in the 2026-07-28 spec?

The 2026-07-28 revision made MCP stateless and tightened OAuth. The changes that matter for security:

The earlier 2025-11-25 revision had already added incremental scope consent via WWW-Authenticate, OpenID Connect discovery, Client ID Metadata Documents, and an HTTP 403 for invalid Origin headers. Together these releases make least-privilege, step-up authorization the expected pattern rather than a nice-to-have.

Are local stdio MCP servers safe to run?

Only as safe as the command that starts them. A local server runs with the same privileges as the user's client. A malicious config line or package can read files, steal SSH keys or run anything. The spec now says clients offering one-click local server setup MUST show the exact command and require explicit approval. It also recommends sandboxing with minimal file system and network access.

The OX Security advisory shows why. Many AI frameworks passed user-supplied commands and arguments straight into the SDK's STDIO launcher, so anyone who could edit a server config could run code. According to OX, Anthropic treated the root behaviour as expected, which puts the burden on the host application. Do not let end users or the model write server launch commands. Keep an allow-list of binaries and arguments, and run local servers in a container or OS sandbox.

What is the MCP security checklist for production?

Run this against every MCP client and server you ship or connect to:

1. Inventory: every server in an internal registry with owner, version, source and approved tool list.
2. Supply chain: pin package versions and hashes; no auto-updates; watch for renamed or typo-squatted packages.
3. Tool pinning: hash descriptions and schemas at approval; alert on changes.
4. Audience-bound tokens: RFC 8707 resource indicators on the client; audience validation on the server; no passthrough.
5. Least-privilege scopes: minimal initial scopes, step-up via WWW-Authenticate; no wildcard scopes in scopes_supported.
6. Issuer checks: validate iss; key credentials by issuer (2026-07-28).
7. Proxy consent: per-client consent, exact redirect URIs, single-use state.
8. URL hygiene: only https (and loopback http in dev) for authorization URLs; never open URLs through a shell; block private IP ranges during OAuth discovery.
9. Sandbox local servers: container or OS sandbox, no home-directory access by default, egress allow-list.
10. Policy gateway: every tool call checked outside the model; outbound tools (email, HTTP, publish) need approval or tight limits when untrusted content is in context.
11. Handles are not auth: random, expiring state handles bound to the authenticated user.
12. Logging: trace tool definitions seen, calls, arguments, policy decisions and results to your SIEM, with OpenTelemetry context.

Items 4, 10 and 12 overlap with agent-level controls. The AI agent control plane post covers identity and kill switches, and the AI agent security checklist covers the rest of the agent.

Does MCP security change in regulated industries like healthcare?

The controls are the same, but the cost of a miss is higher, and you need to prove the controls exist. If an MCP server touches PHI, every server and every model in the path must be covered by a BAA. Tool calls that read patient data need audit logs, and outbound tools need human approval. Our FHIR MCP server guide shows the pattern for EHR data, and building a ChatGPT plugin with MCP covers the public-app side.

How BeevR builds this

We build MCP servers and agents for SaaS and regulated companies, and we run read-only MCP servers on our own sites. Our default design: servers are OAuth resource servers that validate audience and never pass tokens through. Tool definitions are pinned and reviewed like code, and local servers run sandboxed with no secrets in their environment. Every tool call goes through a policy layer that logs the decision and can require human approval. For healthcare work the model can run inside your own AWS account under the AWS BAA, and BeevR signs a BAA as a business associate.

BeevR is a senior, founder-led team in Hanoi. Fixed-scope, fixed-price phases from $10K, a working demo every Friday, and you own the code and IP from day one. See how we build secure AI agents and MCP integrations.

Shipping or connecting MCP servers? Book a 30-minute call and we will run the checklist above against your setup.