MCP Security: 5 Real CVE Classes Every Agent Team Should Know

Five distinct MCP vulnerability classes reached public CVEs or confirmed incidents in 2026, and each maps to a different failure in how agents connect to Model Context Protocol servers. They are: network-binding RCE (MCPJam Inspector CVE-2026-23744), SSRF credential theft (Azure MCP Server CVE-2026-26118), config and hook exploitation (Claude Code CVE-2025-59536 and CVE-2026-21852), trusted-server supply-chain poisoning (postmark-mcp), and tool-description injection. This post covers each class, the actual CVE behind it, and how deterministic detection catches the pattern before the server runs.

I run ATR, an independent, open, MIT-licensed detection standard that PanGuard is built on and operates. The relationship is like Sigma or CVE to the vendor that operates it. What follows is not theory. Every CVE here is verifiable, and every detection claim ties back to rules in a corpus of nearly 690 rules (as of July 2026).

Class 1: Network-binding RCE (MCPJam Inspector CVE-2026-23744)

The MCPJam Inspector bound its interface to 0.0.0.0 by default, meaning it listened on every network interface rather than localhost. In every version before v1.4.3, a single crafted HTTP request from anywhere reachable on the network turned into remote code execution. This is the oldest mistake in the book applied to a new tool category. A developer tool meant for local inspection quietly became a network-exposed RCE surface. Detection catches this class at scan time by flagging 0.0.0.0 and wildcard bind configurations in MCP server code and manifests before the server is ever started. pga scan <target> inspects the server before you install it, so the misconfiguration surfaces during review, not during an incident.

Class 2: SSRF credential theft (Azure MCP Server CVE-2026-26118)

Azure MCP Server CVE-2026-26118 is a server-side request forgery flaw. An attacker coerces the server into making a request to the cloud metadata endpoint, which returns a managed-identity token. That token then grants access to Azure resources the agent was never supposed to reach. SSRF is dangerous precisely because the request originates from the trusted server, so it inherits the server's identity. Detection catches this class by matching on tool calls that fetch internal metadata addresses and on request patterns that reach link-local or metadata IP ranges. The rule fires on the action, not on a string in a description, which is why it survives paraphrasing.

Class 3: Config and hook exploitation (Claude Code CVE-2025-59536 + CVE-2026-21852)

Two CVEs against Claude Code, CVE-2025-59536 and CVE-2026-21852, exploited the hooks system and MCP configuration to achieve arbitrary shell execution and API key theft. Hooks and config files are executable surface. When an untrusted repository or a poisoned config can inject a hook, opening a project is enough to run attacker code and exfiltrate keys. This is the class most agent teams underrate, because they treat configuration as inert data. Detection catches it by scanning .claude/ configuration, settings, hooks, and MCP server definitions for injection patterns, and by treating a hook that spawns a shell as a first-class detection target rather than a benign feature.

Class 4: Trusted-server supply-chain poisoning (postmark-mcp)

postmark-mcp was a trusted MCP server that silently BCC'd between 3,000 and 15,000 emails per day for 15 versions before anyone noticed. Nobody was hijacking the server. The server itself carried the malicious behavior, shipped inside a package teams already trusted. This is agentic supply-chain risk in its purest form: the attack rides the trust you extended to a dependency. Detection catches this class by scanning the server's behavior, not its reputation. A tool that adds hidden BCC recipients or exfiltrates message content is a detectable action pattern regardless of how well-reviewed the publisher looks. This is also why runtime detection matters. Guard watches the actions the server actually takes after install.

Class 5: Tool-description injection

The fifth class is tool-description injection, where an MCP server hides adversarial instructions inside the description of a tool it exposes. When the agent reads the tool list, the poisoned description becomes part of the prompt and can redirect the agent's goal. This maps directly to OWASP Agentic Top 10 categories ASI01 Agent Goal Hijack and ASI02 Tool Misuse and Exploitation. Detection catches this class by treating tool descriptions as untrusted input and matching on injection markers inside them, the same way a prompt-injection rule treats user text. Because the rule reads the description as data, a poisoned tool cannot smuggle instructions past it just by being polite.

How detection catches all five classes

The through-line is that four of these five classes are about actions and configuration, not about a phrase in a user message. That is where deterministic, Layer 1 rules earn their keep. Once an attack is understood, it is written as a rule and then executes in milliseconds for everyone. New attack to rule takes about an hour.

The numbers behind the corpus, always cited as Layer 1 deterministic rules and never as one blended engine score: on the SKILL.md corpus of 498 real-world samples, 100% recall, 97% precision, 0.2% false positives. On the NVIDIA garak in-the-wild jailbreak corpus of 650 samples, 97.2% recall. On a self-built PINT-format corpus of 850 samples, 99.7% precision at 63.6% recall. On HackAPrompt (4,780 samples), 69.6% recall against a 28.6% baseline at 100% precision. False positives on the 65,000-sample benign gate are lane-based: about 0.24% in the enforce lane and about 9% in the hunt lane, which is the default. There is no single blended FP number, and I will not pretend there is one.

For scale context, I scanned 96,096 AI agent skills across six public registries and confirmed 751 as malicious. The five CVE classes above are not edge cases. They are the shape of the threat surface once agents start connecting to MCP servers they did not write.

FAQ

What is the most underrated MCP vulnerability class?

Config and hook exploitation. CVE-2025-59536 and CVE-2026-21852 against Claude Code show that opening a project with a poisoned hook or MCP config is enough to run attacker code, because teams treat configuration as inert data when it is executable surface.

Why did the postmark-mcp incident go unnoticed for so long?

Because it was a trusted server. It BCC'd 3,000 to 15,000 emails per day for 15 versions before detection. Reputation-based trust does not catch a malicious action shipped inside a package you already trust, which is why behavior scanning matters.

Can detection catch tool-description injection reliably?

Yes, by treating tool descriptions as untrusted input rather than trusted metadata. The rule matches injection markers inside the description as data, so a poisoned tool cannot smuggle instructions past it. It maps to OWASP ASI01 and ASI02.

Is ATR the same thing as PanGuard?

No. ATR is an independent, open, MIT-licensed detection standard, governed independently. PanGuard is the free product built on it and operating it, the way a vendor operates Sigma or CVE.

Scan any MCP server or skill before you install it: npm install -g @panguard-ai/panguard && pga up, then pga scan <target>. It is free and MIT-licensed, and the ATR standard is open for you to read and extend.