MCP Limits: Registry Trust and Supply Chain Risks — why 'it's in the registry' is not a safety guarantee before you connect a client

A registry listing tells you who claims ownership of a server, not whether that server is safe to run. No public MCP registry performs code review, security audit, or malware scanning before admission — the gap between "discoverable" and "vetted" is exactly where hijacked and adversarial servers reach a trusted host. This page is the reference a developer (or their coding agent) needs before pointing a client at a server found through discovery, and before deciding what a server they publish must defend against.

Weak Vetting and Ownership Checks in Current Registries

- Registry admission across official and third-party registries requires proof of GitHub repository or domain ownership only, with no code review, security audit, or malware scanning — arxiv.org/abs/2510.16558 (researchers analyzed 67,057 servers across six registries and found widespread conditions enabling server hijacking). - A server listed in the official MCP registry is no more trustworthy than any other community package, yet users commonly assume registry presence implies vetting — arxiv.org/abs/2510.16558, demonstrated through a real-world attack on an unofficial Postmark MCP server (1,500 weekly downloads) that was modified to add a BCC field to its send_email function. - Ownership verification mechanisms rely on repository gateways and environment administrator on-call contacts, but lack rigorous vetting standards; more rigorous vetting would require manifest validation, side-effecting action consent-gating, short-lived token scoping, and SBOM presence — arxiv.org/abs/2510.16558. - A scan with the MCPInspect tool across registries identified 833 vulnerable servers and 18 with suspicious descriptions, indicating weak pre-deployment checks — arxiv.org/abs/2510.16558.

How Adversarial or Hijacked Servers Enter Trusted Hosts

- Attacker-controlled tool metadata can shape LLM reasoning and induce attacker-intended operations, which hosts execute without independent verification — arxiv.org/abs/2510.16558 (core mechanism of tool poisoning attacks; see MCP Limits: Prompt Injection and Tool Poisoning — why the primitives a working server relies on are also its attack surface for the runtime attack surface this feeds). - Compromised servers can be used for prompt injection attacks, allowing exfiltration of private data, manipulation of agent decisions, and silent recording of conversations — authzed.com/blog/timeline-mcp-breaches (documented incidents including GitHub prompt injection exfiltrating private repositories and WhatsApp history exfiltration via tool poisoning). - OAuth endpoint injection in MCP proxy servers enables remote code execution on developer machines: mcp-remote (437,000+ downloads) was compromised through OAuth endpoint injection allowing malicious responses containing shell commands — docker.com/blog/mcp-horror-stories-the-supply-chain-attack/ (CVE-2025-6514, CVSS 9.6, affected 437,000+ development environments). See Authorization in MCP: OAuth 2.1, Token Scoping, and the Confused-Deputy Problem — securing a remote server on the first attempt. - Over-privileged API tokens are catastrophic in MCP workflows; a single compromised dependency can alter agent behavior or introduce execution-level backdoors across every deployment — authzed.com/blog/timeline-mcp-breaches (identified as a recurring pattern in MCP security incidents). This is the mechanism that turns a hijacked server into a MCP Limits: Confused Deputy and Overbroad Permission Scopes — why a server you built safely can still act with someone else's authority problem. - Hosts blindly execute operations based on untrusted metadata without verification, creating a trust-chain breakdown from registry to client — arxiv.org/abs/2510.16558 (core architectural vulnerability).

Supply-Chain Parallels with npm/PyPI Package Ecosystem Attacks

- The MCP ecosystem mirrors npm/PyPI vulnerabilities: thousands of public servers exist from individual developers without formal security review, with new connectors publishing weekly under unclear ownership or maintenance — cycode.com/blog/owasp-mcp-top-10/ (OWASP MCP04:2025 explicitly draws this parallel to traditional supply chain attacks). - Like npm package hijacking, MCP servers can be compromised through credential theft, account takeover, or dependency tampering; the Figma MCP command injection (September 2025) and the Smithery hosting compromise (exposing Fly.io credentials) parallel npm's incident history — authzed.com/blog/timeline-mcp-breaches. - Traditional npm packages are vulnerable to hijacking and tampering without additional security mechanisms; MCP server distribution chains similarly rely on existing package repositories (npm, PyPI) for SDKs and server implementations, inheriting their vulnerabilities — docker.com/blog/mcp-horror-stories-the-supply-chain-attack/ (mcp-remote was distributed via npm and exploited via npm's trust model). - MCP's dependency graph is extensive — a single AI tool may connect to multiple MCP servers, each with its own package dependencies — creating cascading supply chain risk analogous to the leftpad incident in npm — cycode.com/blog/owasp-mcp-top-10/. - Static API key/PAT storage and environment-variable transmission (79% of audited servers) creates supply chain risk analogous to .env file leaks in the npm ecosystem — practical-devsecops.com/mcp-security-statistics-2026-report/ (authentication failure statistics in audited servers).

Incidents and Disclosed Vulnerabilities in the MCP Ecosystem So Far

- CVE-2025-6514 (mcp-remote, v0.0.5–0.1.15): CVSS 9.6 OS command injection enabling full remote code execution on the client operating system when connecting to an untrusted remote MCP server; 437,000+ downloads affected — the first documented case of system-level compromise through MCP infrastructure — practical-devsecops.com/mcp-security-statistics-2026-report/ (primary reference) + docker.com/blog/mcp-horror-stories-the-supply-chain-attack/ (attack mechanism). - Postmark MCP backdoor (September 2025): a malicious MCP server package masquerading as a legitimate "Postmark MCP Server" injected BCC copies of email traffic — including internal memos and invoices, not just message content — to an attacker-controlled server, exploiting the high-privilege access MCP servers commonly run with; the same underlying incident as the BCC-injection attack documented above — authzed.com/blog/timeline-mcp-breaches. - Over 40 CVEs disclosed against MCP implementations (January–April 2026) across the Python, TypeScript, Java, and Rust SDKs, affecting Anthropic's reference servers and third-party tools with 150 million combined downloads — dev.to/piiiico/mcp-security-vulnerabilities-in-2026-40-cves-and-counting-4pco. - 30+ CVEs filed against MCP servers in a single 60-day window (early 2026), with approximately 43% being command-injection patterns — agent-wars.com/news/2026-03-13-mcp-security-2026-30-cves-in-60-days-what-went-wrong. - CVE-2026-33032 (nginx-ui): CVSS 9.8 authentication bypass enabling complete service takeover, actively exploited in March 2026 — authzed.com/blog/timeline-mcp-breaches. - An April 2026 core architectural vulnerability in Anthropic's MCP STDIO transport affected over 150 million downloads across Letta AI, LangFlow, and Windsurf; Anthropic confirmed the behavior is intentional and declined to modify the protocol architecture — dev.to/piiiico/mcp-security-vulnerabilities-in-2026-40-cves-and-counting-4pco. - By mid-2026: 97 million+ monthly MCP SDK downloads, 10,000+ active public servers; vulnerability assessments show 82% vulnerable to path traversal, 43% susceptible to command injection, and 36.7% exposed to SSRF — practical-devsecops.com/mcp-security-statistics-2026-report/. - Authentication gap: of 5,200+ audited servers, only 8.5% use OAuth, 53% rely on static API keys/PATs, 79% transmit credentials via environment variables, and 492 servers were found exposed publicly with zero authentication — practical-devsecops.com/mcp-security-statistics-2026-report/. - A July 2025 internet scan identified at least 1,862 publicly accessible MCP instances responding to unauthenticated requests, despite the MCP authorization spec marking OAuth optional — practical-devsecops.com/mcp-security-statistics-2026-report/. - January 2026: zero-day command injection in an unofficial Gemini MCP tool (CVE-2026-0755). February 2026: a malware distribution campaign cloned the legitimate Oura MCP project, bundling StealC malware — authzed.com/blog/timeline-mcp-breaches.

Cryptographic signing and provenance

Sigstore keyless signing binds server artifacts to audited CI/CD environments without managing long-lived keys — ephemeral keys generated during builds with OIDC authentication prove legitimate origin, preventing compromised developer workstations from successfully publishing malicious updates — mdpi.com/1999-5903/18/5/243 (Trustworthy MCP Registry framework). JSON Canonicalization Scheme (RFC 8785) combined with JSON Web Signatures (JWS) prevents attackers from altering tool definitions mid-session without a valid cryptographic signature — same source (runtime integrity layer). Signed releases and verified publisher signals must be required, not optional, for MCP components, with reproducible builds providing additional provenance verification — cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html. SBOM (or CBOM) visibility should track versions, hashes, licenses, and provenance metadata across MCP component supply chains — owasp.org (MCP04-2025).

Sandboxed execution

secure isolation is non-negotiable for MCP servers executing AI-generated code; container-based isolation (gVisor) and hardware-level isolation (Firecracker microVMs) both reduce host-compromise risk — modal.com/resources/best-code-execution-sandboxes-mcp-servers. Sandboxing controls should enforce read-only file systems by default with write access only to explicitly designated directories, network access constrained to allow-listed endpoints, and resource quotas to contain abuse — cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html. Firecracker microVMs provide hardware-enforced security boundaries; gVisor containers share the host kernel but prevent malicious system calls — the choice depends on whether agents need ephemeral execution or stateful continuity — modal.com.

Allow-listing and governance controls

a centralized allow-list with documented owners, scopes, and data boundaries prevents unknown endpoints from entering host environments; Microsoft recommends teams choose only from pre-approved MCP servers, with nudges toward registration for unknown endpoints — microsoft.com/insidetrack/blog/protecting-ai-conversations-at-microsoft-with-model-context-protocol-security-and-governance/. API gateway centralization requires all remote MCP servers to sit behind a gateway for single-point authentication, authorization, rate-limiting, and logging — same source. Vendor assessment should include security certifications (SOC 2 Type II, ISO 27001), regular penetration testing, detailed security architecture reviews, background checks on ownership and key personnel, and financial-stability evaluation — air-governance-framework.finos.org/mitigations/mi-20_mcp-server-security-governance.html. Static checks should validate that manifests match the contract, consent-gate side-effecting actions, enforce short-lived tokens with proper scoping, and require SBOM presence with current dependencies and no embedded credentials — microsoft.com. Dynamic testing of approved servers should snapshot tool metadata and compare it against contracts, conduct prompt-injection testing, and verify destructive-action handling before publication — microsoft.com. Version pinning with internal package mirrors avoids floating version references that could resolve to compromised packages; dependency scanning via software composition analysis detects CVEs and malicious indicators — owasp.org (MCP04-2025). Network segmentation, service isolation through containers, and circuit-breaker patterns prevent cascade failures when servers are compromised; behavioral analysis of server responses plus threat-intelligence integration enable anomaly detection — air-governance-framework.finos.org. A tiered governance approach is proposed: Tier 1 (centralized proxy with human approval), Tier 2 (automated monitoring), Tier 3 (distributed with comprehensive due diligence), with TLS 1.3+, certificate validation, and mutual authentication mandatory across all tiers — air-governance-framework.finos.org.

For this wiki's objective

a developer connecting a client to a server found through the registry should treat the listing as an ownership claim, not a safety certificate — the incidents above (mcp-remote RCE, Postmark's silent BCC backdoor) both involved servers that were discoverable and, at some point, trusted. A developer building and publishing a server should treat signing, sandboxing, and least-privilege scoping as the baseline a serious deployment needs, not optional hardening — because none of it is enforced by the registry itself.

Related

- MCP Registry and Server Discovery — how a developer finds, publishes, and vets a server before trusting it enough to connect a client — the publishing, versioning, and discovery mechanics that this page's vetting gaps sit on top of: this page answers "why can't I trust what that process surfaces." - MCP Limits: Prompt Injection and Tool Poisoning — why the primitives a working server relies on are also its attack surface — the runtime attack surface a hijacked or adversarial server exploits once it has reached a trusted host through the weak vetting documented here. - MCP Limits: Confused Deputy and Overbroad Permission Scopes — why a server you built safely can still act with someone else's authority — over-privileged API tokens, named above as a recurring pattern in MCP incidents, are the specific mechanism that turns a compromised server into a confused deputy. - Authorization in MCP: OAuth 2.1, Token Scoping, and the Confused-Deputy Problem — securing a remote server on the first attempt — scoped, short-lived tokens (and OAuth endpoint injection as an attack vector, per CVE-2025-6514) are the mitigation layer that limits blast radius once a server from an unvetted registry turns out to be malicious.