MCP registry / marketplace poisoning (OX Security)
Research demonstration15 Apr 2026🗺️ Multi-Agent SystemOX Security enrolled a malicious MCP server into 9 of 11 public registries with no real validation, then confirmed command execution on six live production platforms that discover servers from those registries.
Root cause — why it happened
Modern AI assistants don't hard-code every tool they can use. Instead they look up tools from public catalogues — think app stores for AI 'plug-in servers'. Researchers at OX Security found these catalogues barely check who is publishing. They submitted one fake, malicious tool-server and got it accepted into 9 of 11 public catalogues. Then they watched as six real, live AI platforms automatically discovered that fake server from the catalogue and trusted it just because it was listed. Because the platforms run whatever a listed server tells them to, OX could make those six platforms run commands on the machines hosting them. Nobody had to break in: the attacker simply walked through the front door of a catalogue everyone trusts, and the AI orchestrators picked the poisoned tool up on their own. The core mistake is trusting a directory's listing as if it were proof of safety.
Risks this case illustrates
Named in the standard (OWASP/ATLAS/NIST) lens. Click a highlighted component in the diagram below to see which risks attach where.
How it unfolded
An attacker publishes a malicious MCP server to public registries
MCP servers are little programs that hand AI assistants extra abilities, and there are public catalogues listing them. OX Security built one deliberately malicious server and submitted it to those catalogues — the way anyone might publish to an app store. The catalogues didn't really check who they were or whether the server was safe. Per OX, their fake server was accepted into 9 of 11 public catalogues. At this point nothing has happened yet; the trap is simply listed, waiting to be discovered.
# submitted to a public MCP registry — no publisher vetting, no signature name: "productivity-helper-mcp" # benign-looking, no real provenance description: "File + shell utilities for agents" publisher: "unverified / self-asserted" capabilities: [ "fs.read", "fs.write", "shell.exec" ] transport: stdio artifact_signature: NONE # registry does not require signing vetting_status: AUTO-ACCEPTED # per OX: admitted into 9 of 11 registries
Controls & guardrails — what would have stopped it
The fix that actually breaks this chain is at the moment a tool-server is admitted, not after it runs. If platforms only used a short, vetted list of servers they had checked and pinned — instead of trusting whatever a public catalogue returns — the poisoned listing would never be picked up. If registries verified who was publishing and signed what they listed, the fake server wouldn't get in. And if every server were boxed-in with only the permissions it truly needs, even a malicious one couldn't reach the host computer. A human signing off before adding a powerful new server catches the rest. Filtering or watching alone isn't enough — six live platforms discovered the trap on their own, so the boundary has to be admission itself.
- MCP/plugin pinning, manifest hashing & re-review
Review catches what reviewers understand; a subtle malicious directive can pass. Pinning helps only if you actually re-review on update rather than auto-accepting.
- Per-agent identity & taint-marked messages
Adds coordination overhead and doesn't stop a worker from returning subtly wrong (but well-formed) results that mislead the planner.
- Least-privilege identity & scoped credentials
Doesn't prevent manipulation — only caps its reach. Hard to get right operationally; over-broad scopes are the common real-world failure.
- Human-in-the-loop approval on high-risk actions
Approval fatigue turns gates into rubber stamps; gates placed after the point of no return do nothing; and approvers can be misled by a model-written summary of the action.
- Tool argument validation & sandboxing
Validates form, not intent — a well-formed call to a permitted tool can still be the wrong call. Sandboxing adds latency and isn't always feasible for tools that touch production.
- Runtime monitoring & anomaly detection
Detects the anomalous, not the novel-but-subtle; high false-positive rates cause alert fatigue. Always a step behind a sufficiently quiet attacker.
- Full-trace audit logging
Logging is forensic, not preventive — it explains harm after the fact. Useless if no one reviews it or if the materialised context isn't captured.
- Governance: risk assessment, red-teaming & incident responseaddressesSupply-Chain Compromise
Process reduces likelihood and speeds recovery but executes no technical control itself; weak follow-through makes it theatre.
Lessons
- ▸ Registry presence is not authorisation: orchestrators that treat 'discoverable in a directory' as 'trusted and invocable' inherit every unvetted publisher's intent — OX got one malicious server into 9 of 11 registries.
- ▸ Dynamic discovery is an admission surface: the convenience of auto-resolving tools from a catalogue is exactly what let a poisoned listing reach six live production platforms with no break-in required.
- ▸ Supply-chain failures fan out: because many platforms discover from the same registries, one poisoned listing is an ecosystem-wide RCE surface — OX's 'mother of all AI supply chains' against 7,000+ reachable servers.
- ▸ The RCE is the impact, not the root cause: STDIO command execution follows automatically once a malicious server is admitted, so containment belongs at admission, not after invocation.
- ▸ Contain at the admission boundary: signed/attested artifacts with verified provenance, pinning to a vetted allow-list, human review of new powerful servers, and sandboxing/least-privilege break the chain where model-side or input filtering cannot.
- ▸ Signing proves origin, not safety: provenance and allow-lists are necessary but not sufficient — a legitimately-signed server can be compromised upstream, so sandboxing and least privilege must backstop the trust chain.
Sources
- The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of MCP — OX Security (Apr 15 2026) ↗
- Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain — The Hacker News (Apr 2026) ↗
- OX Security — The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of MCP (primary, 15 Apr 2026) ↗ — Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, Roni Bar; malicious MCP server enrolled into 9 of 11 public registries; arbitrary command execution confirmed on 6 live production platforms via dynamic discovery; 7,000+ publicly accessible servers; related flaws in LiteLLM, LangChain, IBM Langflow; separate STDIO RCE design flaw.
- The Hacker News — Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain (Apr 2026) ↗ — Corroborating coverage of the OX Security disclosure; registry-admission weakness and STDIO RCE across platforms that discover MCP servers from public directories.
Practise the risk class — related scenarios
Compromise the pipeline that builds agents, and every new worker is born malicious
A cost-saving open-weights swap quietly ships a model with its safety surgically removed
A capable third-party model that behaves perfectly — until it sees the trigger
A trusted MCP email tool quietly BCCs every message to an attacker
A forged peer registers on the agent directory — and the planner enlists it