Research Brief

The State of MCP Security in 2026

What 18 months of explosive MCP adoption did to the AI attack surface — and the 10 ways your config is probably exposed right now.

A ShieldMCP research brief. Every figure below is attributed to its source. Where we cite third-party research, it is third-party research — not our scan data.

TL;DR

  • The Model Context Protocol became the de facto integration layer for AI agents in under 18 months, with first-party support across every major model lab.
  • Security tooling did not keep pace. Independent research by Endor Labs found that of 2,614 MCP implementations, 82% were prone to path traversal (CWE-22), 67% to code injection (CWE-94), and 34% to command injection (CWE-78).
  • This is not theoretical. Two real incidents — the Asana tenant-isolation flaw (cross-tenant data exposure across ~1,000 organizations, no external attacker required) and the postmark-mcp malicious server (silently BCC’d outgoing email to an attacker across ~300 orgs) — are exactly the failure modes the spec invites.
  • OWASP published an MCP Top 10 to name these risks. But the tooling to check against it is fragmented across half a dozen non-overlapping vendors, and most of it assumes a security team you don’t have.
  • The fastest thing you can do today: read the 10 categories below, then check your own config against them. ShieldMCP scans a config file against all 10 in about 60 seconds, free.

How MCP became critical infrastructure faster than anyone secured it

Eighteen months ago, “MCP” meant nothing. Today it is the plumbing connecting AI agents to your filesystem, your database, your email, your Stripe account, and your GitHub. MCP became the de facto integration layer for AI agents in under 18 months, with first-party support across every major model lab.

That speed is the problem. MCP spread the way npm packages spread — copy a config snippet from a README, paste it into claude_desktop_config.json or .cursor/mcp.json, restart, done. Nobody reviews those snippets. They grant an autonomous agent real, standing access to real systems, and almost nobody audits what they actually allow.

We’ve seen this movie before. Every integration layer that won on convenience — npm, OAuth scopes, S3 buckets, Kubernetes YAML — went through a period where the default configuration was quietly insecure and the ecosystem only noticed after the breaches. MCP is in that window right now.

What the data actually says

Here is the evidence, with sources. We encourage you to read the originals — links at the end.

Endor Labs analyzed 2,614 MCP implementations

They reported that 82% were prone to path traversal (CWE-22), 67% to code injection (CWE-94), and 34% to command injection (CWE-78). These are not exotic, AI-specific bugs — they are decades-old classes of vulnerability that MCP servers reintroduced because the ecosystem optimized for “works in 5 minutes,” not “safe by default.” Endor’s own framing: MCP is infrastructure, and infrastructure needs classic AppSec discipline.

The Asana tenant-isolation flaw (June 2025)

This exposed data across an estimated ~1,000 organizations, including Fortune 500 companies. The mechanism is the scary part: a caching bug meant AI requests from Organization A could receive cached results belonging to Organization B — project names, task descriptions, metadata — with no external attacker involved at all. Asana took the integration offline for nearly two weeks to fix it. When an integration layer mediates access on behalf of agents, a single isolation bug doesn’t leak one account — it leaks everyone’s.

The postmark-mcp incident (September 2025)

This is the one that should worry you most. An attacker published an npm package impersonating Postmark, built trust over fifteen releases, then in version 1.0.16 added a single line that silently BCC’d every outgoing email to an attacker-controlled domain. It reached an estimated ~300 organizations. Nobody “got hacked” in the traditional sense — people installed it. That’s the MCP threat model in one sentence: the dangerous server is one you added on purpose.

Two patterns connect all three:

  1. 1The risk lives in configuration, not just code. Most of these failures are visible in the config file before anything ever runs.
  2. 2Nobody is looking. There’s no equivalent of a linter, an npm audit, or a pull-request review for the file that grants your agent its powers.

The OWASP MCP Top 10 — mapped to what actually goes wrong

OWASP published an MCP Top 10 — the first dedicated security framework for the protocol — to give these risks names. (It’s a community framework in beta, catalogued MCP01:2025 through MCP10:2025, not yet a ratified standard.) Below is each category, the real-world failure it maps to, and what a config-level scan can catch. ShieldMCP runs a dedicated check for all ten.

#OWASP MCP riskWhat it looks like in a real configWhat a scan catches
MCP01Token Mismanagement & Secret ExposureAPI keys, tokens, and secrets pasted in plaintext directly into the configHardcoded secrets sitting in claude_desktop_config.json / .cursor/mcp.json
MCP02Privilege Escalation via Scope CreepA filesystem server pointed at / or ~; a DB server with full write; live payment keysOverly broad filesystem, database, and API access granted beyond task requirements
MCP03Tool PoisoningAn unverified server package carrying prompt-injection payloads — the postmark-mcp pattern; configs with hidden zero-width characters or embedded directivesServers sourced from unverified/malicious packages; invisible characters and directive smuggling in config values
MCP04Software Supply Chain Attacks & Dependency TamperingUnpinned versions, npx straight from a Git URL, scoped packages without version pins (dependency confusion)Risky package sourcing: unpinned versions, Git-URL installs, dependency-confusion exposure
MCP05Command Injection & ExecutionServer args that build shell commands from untrusted inputDangerous command patterns enabling shell injection / arbitrary code execution
MCP06Intent Flow SubversionFetch/browser/email servers that pull untrusted external content into the agent contextServers that ingest external content carrying indirect prompt-injection payloads
MCP07Insufficient Authentication & AuthorizationA remote server over plain http://, no auth; server bound to 0.0.0.0Insecure transport, missing/weak authentication, and public network binds
MCP08Lack of Audit and TelemetryNo log of which tools the agent called or what data it touchedAbsence of any audit trail for agent tool calls and data access
MCP09Shadow MCP ServersServers added ad hoc that no one tracks or reviewsHidden, unofficial, or improperly configured servers that evade audit
MCP10Context Injection & Over-sharingEmail + files + database all connected to one agent (PII trifecta); a data source (your DB) and a data sink (email/web) on the same agentPII over-aggregation and source+sink combinations that create an exfiltration pathway

Read the table as a checklist. If you can’t confidently say “no” to every row for your own setup, you have findings.

The two that bite hardest in practice are MCP05 / MCP10 — the combination risks. Any single server may look fine. It’s the pairing — a database server next to an email server, on an agent with no logging — that turns a normal setup into a one-prompt exfiltration path. These are exactly the risks a human eyeballing the file tends to miss, because each line looks reasonable on its own.

Why the tooling hasn’t saved you

There are MCP security tools. That’s part of the problem. The space is fragmented across non-overlapping vendors — Invariant/Snyk’s mcp-scan, Cisco’s mcp-scanner, MCPSafe, Backslash, Promptfoo, Microsoft’s Agent OS — and no single one covers the full OWASP MCP Top 10. Each catches a slice. Stitching them together is a security-team project, and the people most exposed — solo builders, two-person teams, automation agencies wiring up MCP for clients — don’t have a security team.

So the practical state of MCP security in 2026 is: a named, public list of the top 10 risks, real breaches demonstrating them, and no simple way for a non-specialist to check their own config against the whole list.

That gap is the entire reason ShieldMCP exists.

What to do this week

You don’t need a budget or a security hire to close most of your exposure. In rough priority order:

  1. 1Get every secret out of your config. Move API keys and tokens to environment variables or a secret manager. This kills MCP01 outright and it’s the single highest-leverage fix.
  2. 2Right-size permissions. Point filesystem servers at a specific project directory, never / or ~. Use read-only DB credentials wherever the agent doesn’t need to write. (MCP04)
  3. 3Audit your server list and kill the shadows. If you can’t say what a server does and who publishes it, remove it until you can. (MCP06, MCP02)
  4. 4Look for source + sink pairs. If one agent can both read sensitive data and send/post it outward, that’s your exfiltration path — separate them or add controls. (MCP05, MCP10)
  5. 5Pin your versions and check publishers. No unpinned @latest, no npx straight off a Git URL you haven’t read. (MCP09)
  6. 6Turn on transport security and auth for any remote server. No plain HTTP. (MCP08)

Sources

All links below were verified June 2026.

Or check all ten in 60 seconds

ShieldMCP scans your MCP config file against the full OWASP MCP Top 10 and returns a risk score, per-server breakdown, and a categorized list of findings — free, no account required.

Run a free scanRead the docs