MCP Tool Poisoning, and the RCE You Inherited: Reading the June 2026 Disclosures

Short answer up front. "MCP tool poisoning" is the search everyone is running this month because the problem stopped being a research demo and became a default you ship without reading. A poisoned tool description hides instructions inside the metadata your agent trusts at boot. A rug pull swaps a clean tool for a dirty one after you already approved it. And on June 16, 2026, OX Security disclosed what it describes as a remote-code-execution flaw in the official Model Context Protocol SDKs themselves, which - by their account - means a lot of teams inherited the bug without writing a line of bad code. If your agent talks to an MCP server you did not build, this is your week to audit.

We already published a byte-level walkthrough of how the attack works. This post is the other half: the current numbers, what actually shipped in the last stretch, and a checklist you can run against your own environment instead of reading about someone else's.

Why this is suddenly everyone's search

Two things collided. The first is slow: for a year, security teams have been measuring how much of the public MCP ecosystem is already compromised, and the figures kept getting worse. The second is fast: on June 16, the OX Security research team disclosed what they called the mother of all AI supply chains - a command-execution flaw that is not a bug in one product but a design default baked into Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust. Build on the reference implementation, inherit the exposure. Their estimate is up to 200,000 vulnerable instances riding a supply chain with more than 150 million downloads and 7,000-plus publicly reachable servers. A successful hit hands an attacker user data, internal databases, API keys, and chat history.

That is the headline, but it lands on top of a problem that was already structural. Here is the part the diagram makes obvious.

A tool description, a system prompt, and a user message all arrive in the same context window at the same trust level. The model has no mechanism to treat one as documentation and another as a command. So if an attacker controls a tool's description, they control an instruction the agent will read and obey - on every call, in every session, for every user, until somebody notices.

Three different things people mean by "MCP tool poisoning"

The search term is one phrase, but it covers three distinct failures. Telling them apart is the first step to checking for them.

• Tool poisoning (classic). Malicious text inside a tool's description field. The agent reads it during tools/list and follows it. This is the one Invariant Labs named in April 2025.
• Rug pull. A tool that was clean when you approved it, then quietly changes its definition afterward. No re-approval is triggered, so a trusted tool turns hostile without anyone clicking yes again. The postmark-mcp npm backdoor in September 2025 was the first documented in-the-wild case; it reached roughly 1,500 weekly downloads and about 300 organizations before discovery.
• Transport / SDK-level RCE. Not about the description at all - a flaw in how the server process is launched or how the SDK handles input, leading to command execution. The June 16 OX Security disclosure is this kind, and so was the earlier mcp-remote chain.

When you see the long-tail query "mcp security prompt injection tool poisoning," that is people trying to work out which of these three hit them. The honest answer is that the first two are prompt injection wearing a supply-chain costume, and the third is plain old remote code execution that happens to live in AI plumbing.

The numbers, as of mid-June 2026

None of this is hypothetical anymore. The measurements have been done, repeatedly, by people who publish their method.

Read the second row twice. An agent with auto-approval turned on - which is the default developer experience for most MCP clients - obeys a poisoned tool more than four times out of five. The convenience setting is the exploit.

The disclosure timeline

If you want one thing to send your platform team, send them this. The pattern is a named class of attack moving from demo to CVE to inherited default in about fourteen months.

The Vulnerable MCP Project now tracks more than 50 known MCP weaknesses, 13 of them critical. That is not a protocol with a few rough edges. That is a protocol whose trust model has not caught up with where it is deployed.

What to check in your own stack this week

This is the part you can act on without waiting for a vendor. None of it needs a new product; most of it is inventory and defaults.

1. Pin and diff every MCP server you did not write. Record the exact version and a hash of its tool list. A rug pull is invisible unless you can compare today's tool descriptions against the ones you approved. If you cannot produce that list right now, that is finding number one.
2. Turn off auto-approval for any tool that reaches the network, the filesystem, or a shell. The 84.2% figure is an auto-approval figure. A human-in-the-loop on a sensitive tool call is unglamorous and it works.
3. Read the tool descriptions. Literally. Poisoned metadata often hides instructions in whitespace, unicode, or text positioned to be invisible in a UI but plain to the model. If your client never surfaces the raw description an agent receives, you are trusting text you have never seen.
4. Patch the SDK, then check what shipped with it. For the June 16 issue, update to the fixed SDK release, then inventory the downstream packages that bundled the vulnerable default - the exposure rode a 150-million-download supply chain, so the fix is not one bump, it is a sweep.
5. Get credentials off the path a poisoned tool can reach. The GitGuardian count - thousands of still-valid secrets sitting in public MCP configs - is the reason a tool-poisoning hit turns into a breach instead of a scare. Short-lived, scoped credentials make a stolen one a dead end.
6. Put an allowlist in front of what an agent can call. A gateway that permits a known set of tools and destinations and nothing else means a hidden instruction in a description has nowhere to send what it reads.

For the auditor in the room, this maps cleanly to the OWASP Agentic Top 10 - ASI02 for tool misuse and the supply-chain entries for the SDK and package layer - and to the OWASP LLM Top 10 LLM03 supply-chain control. "We pin and diff our MCP servers on a schedule" is a sentence an assessor can verify; "we trust our vendors" is not.

Why a one-time review will not hold

The thing that makes this hard is the same thing that made the LiteLLM and LangGraph CVEs hard earlier this month: the layer moves faster than your review cycle. A tool you audited in May can rug-pull in June. An SDK you vendored last quarter can ship a command-execution default this quarter. The control that matters is not a clean report from one afternoon; it is proof, on a schedule, that the tool descriptions and SDK versions you trust are still the ones you checked.

That is the whole reason continuous AI security posture management exists as a category. Not because a posture platform blocks a live exploit - it does not, and anyone who tells you otherwise is selling a story - but because the MCP surface is testable, and in a stack that ships a new poisoned-tool report most months, "we reviewed that once" is not an answer.

What Penaxtra does about it

Penaxtra treats every MCP server and agent as a first-class asset. It enumerates the tools each one exposes, runs safe adversarial probes for the poisoning and rug-pull shapes above, flags a tool whose description changed since you approved it, and maps each finding to the OWASP Agentic Top 10, OWASP LLM Top 10, NIST AI 600-1, and the EU AI Act before it reaches your queue. Because the checks run on a cadence, a description that quietly changes - or an SDK bump that reintroduces a known default - shows up as a finding instead of a breach. Start with the MCP security checklist, read the tool poisoning glossary entry, or request an architecture review and we will walk your agent and MCP setup with you.

Related reading

• MCP Tool Poisoning: How the Attack Works and How to Stop It
• The MCP Security Checklist
• LiteLLM, LangGraph, and the June 2026 AI-infrastructure CVEs
• OWASP Agentic Top 10 walkthrough
• Frontier Agents Cut Both Ways - the first in-the-wild LLM-agent intrusion