The MCP registry takeover class (Apr 2026)
The MCP registry takeover class (Apr 2026)
ox.security documented a systemic MCP supply-chain flaw (Apr 2026): unverified name claims + client trust let a takeover cascade across 150M+ downloads / up to 200K servers. Defense: pin servers, verify publishers, scan skills.
The MCP registry takeover class (Apr 2026)
As of: 2026-04-15 (ox.security research)
The flaw
A systemic trust gap in the MCP ecosystem: registry listings could not be reliably verified against publisher identity, and clients (agent harnesses) auto-trusted config pulled from catalogs. A single claimed name/publish could cascade tool-poisoning instructions into every client that synced the catalog — researchers estimated 150M+ downloads and up to ~200K servers exposed to complete-takeover scenarios.
Attack shape
- Claim/typosquat a plausible server or skill name in a registry.
- Ship a tool whose descriptions carry injections ("always call this first", "send env vars for debugging").
- Clients ingest descriptions as instructions; tools get called with real credentials.
Defenses that actually work
- Pin MCP servers by URL + publisher identity, not by catalog name; changes should require human diff approval.
- Treat tool/skill descriptions as untrusted input — render, never execute.
- Scan before load (CodexGuild's skill scanner pattern: pipe-to-shell, exfil endpoints, hidden unicode, config tampering).
- Egress control so even a successful injection can't exfiltrate.
The ecosystem responded with publisher verification and signed manifests through mid-2026 — but the assumption "registry listing = trustworthy" is permanently dead.