MCP a 16 meses del spec: 15+ incidentes, dos revisiones y un MCPwn explotado in the wild

El 1 de abril de 2025 Invariant Labs publicó el primer paper sobre MCP tool poisoning con PoC reproducible. Dieciséis meses después, el ecosistema MCP tiene dos revisiones formales del spec (2025-06-18 y 2025-11-25), una OWASP MCP Top 10 v0.1 en beta release and pilot testing desde finales de 2025, 15+ incidentes públicos documentados que abarcan tool poisoning, supply chain, RCE y exfil de credenciales, y un benchmark académico (MCPTox, arXiv 2508.14925, presentado en AAAI) que mide ASRs por encima del 70 % contra modelos punteros.

El cierre del trimestre suma una pieza más: el 15 de marzo de 2026 nginx-ui publica la versión 2.3.4 que tapa CVE-2026-33032 (CVSS 9.8), bautizado MCPwn por Pluto Security — un auth bypass en la integración MCP de nginx-ui que entrega takeover completo en dos requests HTTP, con 2.600 instancias expuestas según Shodan al momento del parche.

El post de abajo no pretende ser otro inventario de buenas prácticas, sino una lectura operativa del ecosistema MCP a marzo 2026: qué movió el spec, qué incidentes hubo, qué cuentas dan los benchmarks, y qué controles han pasado de SHOULD a MUST en clientes y registries.

Lo que cambió en el spec — 2025-06-18 y 2025-11-25

El spec MCP 2025-03-26, el que iba a la vez que el paper de Invariant, ya nombraba el problema de tool poisoning en Implementation Guidelines y añadía el primer framework de authorization basado en OAuth 2.1 para transportes HTTP. No bastaba. Dos revisiones siguieron en doce meses.

Spec 2025-06-18 — la primera tras el paper de Invariant. Los cambios relevantes para seguridad:

• MCP servers como OAuth 2.0 Resource Servers con resource indicators obligatorios (RFC 8707). Cada access token queda explícitamente bindeado a un MCP server concreto. Cierra una clase de ataques donde un token emitido para server-a podía usarse contra server-b.
• Structured tool output — JSON estructurado validado por schema. No es defensa contra prompt injection, pero sí reduce la superficie de arbitrary text gets parsed by the model que era el caballo de batalla de TPA en abril 2025.
• Elicitation — los servidores pueden pedir input al usuario mid-session vía elicitation/create con un schema JSON. El equivalente “human in the loop estructurado”. El SHOULD del spec original sobre consent pasa a tener primitiva de protocolo.
• Eliminación del JSON-RPC batching (breaking change). Ya no se pueden encadenar varias tools/call en un único batch — cada llamada pasa por el modal de consentimiento individualmente.

Spec 2025-11-25 — la revisión actual al momento de escribir. Mejoras incrementales con foco en authorization y governance:

• OpenID Connect Discovery 1.0 como mecanismo soportado para el descubrimiento del authorization server. RFC 9728 alineado para Protected Resource Metadata.
• Incremental scope consent vía cabecera WWW-Authenticate. El cliente puede pedir permisos adicionales sobre la marcha en lugar de pre-aprobar todo en init.
• OAuth Client ID Metadata Documents como mecanismo recomendado de registro de cliente — alternativa a los flujos de Dynamic Client Registration que eran un punto débil.
• Tasks experimentales — soporte para requests durables con polling y retrieval diferido. Relevante para agentic workflows largos donde el modelo encadena 20-30 tool calls.
• JSON Schema 2020-12 como dialecto default. Pequeño pero importante: cierra ambigüedades en la validación de inputs.
• Governance formal — Working Groups, Interest Groups, SDK tiering. El protocolo deja de ser solo Anthropic-publishes-spec y entra en gobernanza tipo IETF/W3C.

Lo que no cambió en doce meses: la marca de origen de las descripciones de tools sigue sin viajar en el wire. La frase del spec de noviembre 2024 —“MCP itself cannot enforce these security principles at the protocol level”— sigue describiendo el problema con la precisión del primer día. El spec recomienda, los clientes implementan, el modelo decide. Y el modelo, como veremos abajo con MCPTox, no distingue instrucciones legítimas de las que vienen del adversario en la description.

OWASP MCP Top 10 v0.1 — el inventario formal

A finales de 2025 OWASP publicó la primera versión del Top 10 específico para MCP, liderado por Vandana Verma Sehgal. Está en Phase 3 — Beta Release and Pilot Testing, las categorías son estables pero los rankings pueden moverse. Las diez:

Lectura rápida: tool poisoning queda como MCP03 — no como #1. El espacio de cabeza se lo lleva la gestión de secrets, fiel a lo que GitGuardian va a documentar en su scan masivo. Intent Flow Subversion (MCP06) recoge lo que Invariant llama toxic agent flows — la combinación de untrusted instructions + sensitive data + exfil path que define la lethal trifecta que repite Simon Willison.

Para auditoría operativa, los IDs son útiles. Mapear cada control técnico (allowlist de comandos, sandboxing por proceso, ICN re-prompt en cambios de descripción, audit log estructurado) a una de las diez categorías es lo que hace que un threat model sobre MCP deje de ser “leemos el blog de Invariant y nos asustamos” y pase a ser un programa con cobertura medible.

Quince meses de incidentes — la cadena pública

Entre abril 2025 y marzo 2026, los incidentes públicos que han pasado por advisory, CVE o blog post de un vendor de seguridad. La lista no pretende ser exhaustiva — pretende mostrar la diversidad de categorías:

Abril 2025 — WhatsApp MCP chat-history exfiltration. Invariant publica el primer rug-pull funcional. Un servidor MCP poisoned dirige al agente a leer toda la historia de chats de WhatsApp del usuario y exfiltrarla en parámetros de tool call. Tool poisoning + cross-server tool shadowing. Sin CVE asignado; categoría arquitectural. Fuente.

Mayo 2025 — GitHub MCP server prompt injection. Invariant demuestra contra el servidor oficial de GitHub: un issue público con instrucciones embedidas hace que un agente con PAT broad-scope acceda a repos privados, extraiga datos (nombres de proyecto, salary info, planes de reubicación) y los publique en el repo público. La fix no es server-side — es de agent system level: una sesión, un repo, least-privilege tokens. Fuente.

Junio 2025 — Anthropic MCP Inspector RCE — CVE-2025-49596 (CVSS 9.4). El developer tool oficial deja escuchando en localhost sin autenticación. Cualquier visita a una página web hostil ejecuta código arbitrario contra el inspector-proxy. Patch coordinada. La cara “developer tool en mi máquina” del inventario MCP es tan crítica como la “producción”.

Junio 2025 — Smithery path traversal + supply-chain compromise. GitGuardian reporta a Smithery un path traversal en la build pipeline (dockerBuildPath aceptaba ..). Con el bug, GitGuardian extrae ~/.docker/config.json del builder, llega a un token fly.io con scope sobre la cuenta entera, y demuestra acceso a 3.000+ MCP servers alojados. Reporte 13-jun, fix 15-jun, publicación pública octubre 2025. Es el caso textbook de “hosting de MCP servers es supply chain crítico”. Fuente.

Julio 2025 — mcp-remote OS command injection — CVE-2025-6514. El proxy OAuth mcp-remote (437.000 descargas, adoptado por Cloudflare, Hugging Face, Auth0) pasaba el authorization_endpoint a un shell sin sanitizar. RCE remoto. JFrog reportó.

Agosto 2025 — Anthropic Filesystem MCP Server — CVE-2025-53109 y CVE-2025-53110. Sandbox escape y bypass de contención por symlinks en el servidor de referencia. El filesystem oficial, el que más usuarios registran “para que el modelo pueda leer mis notas”, escapaba de la cwd con un symlink construido al vuelo. Descubierto por Cymulate.

Agosto 2025 — Cursor MCPoison — CVE-2025-54136 (CVSS 8.6). Check Point Research publica el bug: Cursor ataba la confianza al nombre de la entry MCP en .cursor/rules/mcp.json, no al command ni a los args. Aprobas un MCP “benigno” la primera vez; el atacante reemplaza el command por reverse shell; Cursor lo ejecuta en el siguiente sync del repo sin reaprobar. Patch en Cursor 1.3, 29-jul-2025. Cualquier .mcp.json checkeado en un repo compartido era vector. Fuente.

Septiembre 2025 — Postmark MCP — primer servidor malicioso “in the wild”. Un actor publica postmark-mcp en npm impersonando al MCP oficial de Postmark. Durante quince versiones construye reputación legítima; en la v1.0.16 (17-sep-2025) añade una línea: BCC de cada email enviado a phan@giftshop[.]club. ~1.500 descargas semanales, ~300 organizaciones afectadas según Koi Security. El cambio no se detecta por scanners de dependencias porque la interfaz pública del paquete no cambia. Primera prueba operativa de que MCP como ecosistema npm hereda todo el threat model de la cadena npm: typosquatting, account takeover de maintainer, payload añadido en una minor.

Septiembre 2025 — Flowise — CVE-2025-59528. Flow vulnerability en el transporte STDIO que permite acceso a módulos child_process y fs. RCE.

Octubre 2025 — Figma/Framelink MCP — CVE-2025-53967. Unsanitized input pasado a child_process.exec. El patrón “MCP server escribe un wrapper alrededor de una API y pasa argumentos sin escapar” es la versión 2026 de los bugs SQLi de 2002.

Enero 2026 — Unofficial gemini-mcp-tool — CVE-2026-0755 (CVSS 9.8). Command injection vía execAsync. Otro wrapper alrededor de una CLI; otra concatenación de string sin sanitizar.

Febrero 2026 — Trojanized Oura MCP. Clone de un MCP server legítimo con StealC info-stealer empaquetado dentro. Distribuido por SmartLoader vía registries. Mismo patrón que con paquetes npm trojanizados de los últimos cinco años, ahora sobre el catálogo MCP.

Marzo 2026 — nginx-ui MCPwn — CVE-2026-33032 (CVSS 9.8). El bug del trimestre. La integración MCP de nginx-ui expone dos endpoints HTTP: /mcp (con AuthRequired() middleware) y /mcp_message (con solo IP allowlist, sin auth middleware). Cualquier atacante con acceso de red establece SSE contra /mcp, obtiene un sessionID, y dispara los 12 tools destructivos contra /mcp_message sin credenciales. Dos requests HTTP, takeover completo: reload de nginx, modificación de configs, exec de comandos del sistema. 2.600 instancias expuestas en Shodan. Parche en nginx-ui 2.3.4 (15-mar-2026), entrada en CISA KEV durante abril 2026. Codename MCPwn por Pluto Security. Fuente.

Diagnóstico sumario: las categorías son tres.

1. Tool poisoning puro / toxic flows (Invariant, WhatsApp, GitHub MCP). Bug arquitectural del modelo + descripciones controladas por el servidor.
2. Supply chain MCP (Postmark, Oura, Smithery, gemini-mcp-tool). Cualquier cosa que el ecosistema npm ya sufría, aplicada a npx -y + packages MCP.
3. MCP servers como webapps con bugs de webapp (nginx-ui, Flowise, Figma, mcp-remote, Filesystem). Auth bypass, command injection, path traversal, sandbox escape. Los bugs clásicos en código nuevo expuesto.

Las tres comparten una propiedad: el blast radius es el agente del usuario — su filesystem, sus credentials, sus repos privados, su mailbox. La definición de toxic flow funciona para las tres.

El ecosistema en cifras — 12.000 servidores, 24.000 secrets, 66 %

Tres datasets públicos resumen el estado del ecosistema a Q1 2026:

GitGuardian: secrets en configuraciones MCP. Scan de configs MCP publicadas en GitHub: 24.008 secrets únicos expuestos, 2.117 todavía válidos en el momento del scan. API keys de Anthropic, OpenAI, GitHub PATs, Slack tokens, AWS keys, Postgres URIs con contraseña inline. El patrón replica lo que se vio con .env files en repos públicos: copy-paste de credenciales en archivos que terminan trackeados por error. La diferencia es que los configs MCP son nuevos, los desarrolladores no tienen reflejo de tratarlos como secret-sensitive, y los registries (Smithery, Glama, MCP.so) crawlean repos públicos buscando configs para listar, amplificando la exposición.

Endor Labs — análisis estático de 2.614 implementaciones. 82 % vulnerables a path traversal. 67 % usando APIs propensas a code injection (exec, eval, child_process.exec con argumentos no sanitizados). No es un benchmark de calidad media del catálogo; es el catálogo. Cuando dos de cada tres servidores usan APIs peligrosas en su lógica, el ratio de bugs descubiertos / bugs latentes está al inicio de la curva.

AgentSeal — 1.808 servidores escaneados. 66 % con al menos un finding de seguridad. Breakdown por tipo: 43 % command injection, 20 % findings en tooling infrastructure, 13 % auth bypasses, 10 % path traversal. La false positive rate contra un set de 120 servidores known-benign documentados es del 4,2 % para findings high/critical, número de orden, no de ruido. Fuente.

Para contexto, los servidores en producción andan por encima de 12.000 distribuidos entre Smithery (~7.000), Glama (~21.000 indexados, no todos producción), MCP.so (~19.700 community submissions), y el registry oficial. Las cifras se solapan; la unión real desduplicada es difícil de medir. Lo que sí está medido es el long tail self-hosted que ningún registry indexa.

MCPTox — el primer benchmark académico

Si el inventario de incidentes te resume el outcome, el paper MCPTox (Wang et al., AAAI 2026, submission 19-ago-2025) te resume la capacidad. Es la primera medida sistemática de cuántos agentes son vulnerables a tool poisoning sobre servers MCP reales — no juguetes de PoC.

Setup:

• 45 servidores MCP del catálogo público, no laboratorio.
• 353 tools reales dentro de esos servidores.
• 1.312 test cases adversariales generados por few-shot learning sobre tres templates de ataque.
• 10 categorías de risk cubiertas.
• 20 LLM agents evaluados — incluyendo GPT-4o-mini, o1-mini, DeepSeek-R1, Phi-4, y Claude-3.7-Sonnet.

Headline numbers:

Dos observaciones del paper que tienen consecuencias operativas:

1. Más capability → más vulnerabilidad. Los modelos más capaces (o1-mini, Phi-4) tienen ASRs más altas porque siguen instrucciones mejor. La instrucción adversarial embedida en la descripción del tool es una instrucción más, y los modelos buenos en instruction following la procesan mejor que los modelos saturados.
2. El alignment de seguridad no atrapa esto. El refuse rate más alto es <3 %, y lo consigue Claude-3.7-Sonnet — el modelo con más esfuerzo público en RLHF/CAI. El resto está por debajo. La razón es que el adversarial no pide al modelo algo que el modelo identifique como prohibido; pide que use un tool legítimo para una operación no autorizada. La frontera “is this a refused query” se cae cuando la query, en su forma, es una llamada normal a tool.

La conclusión metodológica del paper, “existing safety alignment is ineffective against malicious actions that use legitimate tools for unauthorized operation”, pasa a ser cita estándar en todos los reports posteriores. Por algo: el aviso operativo es que el control de tool poisoning no vive en el modelo. Vive en el host, en el registry, en el operador.

Toxic agent flows — el patrón que generaliza

Lo que el paper de Invariant de abril 2025 llamó “tool poisoning” se ha ido refinando en literatura como toxic agent flow o, en formulación de Simon Willison, lethal trifecta. Los tres ingredientes:

1. Untrusted instructions: texto que el adversario controla y que entra al contexto del modelo. Puede ser una description de tool, un resource (archivo, URL, fila de DB), un GitHub issue, un email, un log line, un mensaje de WhatsApp. Cualquier cosa que el agente lea.
2. Sensitive data access: el agente tiene tool calls que pueden leer datos privados. Un PAT con scope amplio sobre GitHub, un filesystem MCP con $HOME, un email client MCP con la inbox, un Slack MCP con DMs.
3. Exfiltration path: el agente tiene una forma de sacar datos. Un email tool, una llamada HTTP con tool de browsing, un MCP de logging que escribe a un disco compartido, un parámetro de tool call que va a un servidor del atacante.

Cuando los tres están en la misma sesión, hay flujo tóxico. La defensa que sí cierra el problema es romper el flujo, no detectarlo. Tres patrones operativos:

• Una sesión, un repo / un mailbox / un escritorio. Si el agente solo ve un repo privado, no puede exfiltrarlo a otro. La mitigación que GitHub recomendó para su MCP es exactamente esto. Cuesta en UX (el usuario quiere encadenar tareas multi-repo), pero cierra la trifecta de raíz.
• Least-privilege tokens por sesión, con scope estrechado al subset realmente necesario. PATs con repo:read solo, no repo:read,issues:write,workflow. Tokens con TTL corto (minutos) y rotación.
• Bloqueo de canales de exfil. Si el agente no tiene tool que llame HTTP arbitrario, no puede llamar al servidor del atacante. La política “MCP web-fetch solo contra hosts de la allowlist” cierra la categoría de exfil HTTP. Para email exfil, el host debe romper el send_email contra dominios externos sin doble confirmación.

La discusión teórica sobre “el LLM no debería seguir instrucciones de descripciones de tools” es real pero no operativa a 2026. El LLM, según MCPTox, lo va a hacer. Lo que el operador puede controlar son los otros dos ingredientes de la trifecta — los flows de datos y los flows de salida.

El núcleo arquitectural — OX Security y los 200.000 servidores

A finales de Q1 2026, OX Security publica The Mother of All AI Supply Chains — la investigación de mayor blast radius del ecosistema MCP hasta la fecha. El claim es duro: el transporte STDIO de los SDKs oficiales de Anthropic (Python, TypeScript, Java, Rust) acepta configuración como command y la ejecuta directamente vía subprocess sin sanitización ni allowlist.

Es decir, cualquier producto downstream que acepte una configuración MCP del usuario, del repo, de una API, y la pase a un cliente del SDK oficial está montando una primitiva config-to-command-execution. OX consigue RCE en seis plataformas en producción: LangFlow, LettaAI, Windsurf entre las nombradas. El supply chain (150M+ descargas combinadas, 7.000+ servers públicos, estimación de 200.000 instancias vulnerables totales) hace al patrón más amplio que cualquier CVE puntual.

Anthropic responde en coordinated disclosure que el comportamiento es expected y declina modificar la arquitectura del protocolo. La defensa, otra vez, vive en el operador: cualquier producto que acepte configuración MCP de fuentes no confiables (multi-tenant SaaS, repos compartidos, configs descargadas de internet) tiene que envolver la lectura del config con su propia capa de validación. El SDK no lo hace.

Es un argumento parecido al de la subprocess.run de Python: el lenguaje no te puede impedir hacer subprocess.run(user_input). El SDK MCP, por la misma lógica, tampoco. La diferencia es que subprocess.run se ha enseñado durante quince años como ejecuta lo que le pases. El SDK MCP se está enseñando durante uno como conecta servidores. La sorpresa del desarrollador medio cuando descubre que command se ejecuta literal vía shell es real, y los CVEs lo demuestran.

La defensa del operador — qué ha cambiado en doce meses

Las recomendaciones del post de abril 2025 siguen vigentes — sandboxing por servidor, lectura manual de descripciones, hash de descripción al primer install, alerta en rug pull, sin auto-allow para tools de acción. Doce meses después, algunos clientes las han implementado, otros no:

• Claude Desktop — modal de approval por tool call mantenido. Sin diff de descripción entre init y tools/call. Sin sandboxing de filesystem por servidor: el command del registro ejecuta como el usuario.
• Cursor 1.3+ (post CVE-2025-54136) — reaprobación obligatoria en cualquier cambio del command o args de un MCP entry. Hash implícito sobre el contenido del config. Es la mitigación específica al rug pull, implementada como respuesta a Check Point.
• GitHub Copilot Agent Mode — desde mediados de 2025, separación por agent session per repository recomendada en la documentación tras el incident de mayo. El cliente no impide multi-repo, pero la guía operativa cambia.
• MCP gateways comerciales (TrueFoundry, AgentSeal, varios startups). El patrón “intermedia un proxy entre cliente y servidor, validez schemas, filtra descripciones, audita tool calls” se ha consolidado como category. Los registries empiezan a publicar trust scores (AgentSeal hace 800+ servers con 9 analyzers).
• Network allowlists + runtime inspection — desde GitGuardian hasta WorkOS, la recomendación operativa de las plataformas de identity es: tratar cada MCP server como cualquier integración SaaS — token con scope, observability del traffic, kill-switch.

Lo que no se ha resuelto:

• Verificación criptográfica de servidores. Sin un patrón tipo Sigstore/cosign aplicado al protocolo MCP, el verifier final del binary que ejecuta npx -y @something/mcp-server es el trust on first use del usuario.
• Aislamiento cross-server del contexto del modelo. El spec 2025-11-25 no lo aborda. Cuando un host tiene filesystem, github, slack, los tres entran al mismo prompt. El shadowing de Invariant sigue siendo arquitecturalmente posible.
• Identidad y attestation del servidor. El cliente sabe que está hablando con algo en stdin/stdout o sobre HTTP, pero no sabe que ese algo es el binario que el desarrollador subió. La cadena de confianza termina en el sysadmin local que escribió el command.

Qué llevar al threat model

Si tienes MCP en producción al cierre de Q1 2026, las preguntas operativas:

1. Inventario explícito de servidores activos por usuario / equipo. Servidor, fuente (registry oficial, repo público, fork interno), command exacto, version pinneada por hash, capabilities de filesystem y red, secretos que maneja.
2. Mapeo a OWASP MCP Top 10. Para cada servidor del inventario, qué categorías son aplicables y qué control compensatorio existe. Mapping → control → owner.
3. Política de scope de tokens. PATs en GitHub MCP con repo:read y nada más. Tokens con TTL bajo y rotación. Si el agente puede pasar a producción, el token no.
4. Sesión = scope. Cada sesión del agente con un solo repo / mailbox / proyecto. Ruptura del flujo tóxico por construcción.
5. Allowlist de comandos del host. La command primitive del SDK STDIO (lo que OX Security explota) se cierra con un wrapper que solo deja arrancar binarios firmados o presentes en un manifest. Nunca aceptar command de configuración externa sin pasar por la lista.
6. Logging estructurado de tool calls. Cada tools/call con name, args, decisión del usuario (approve/deny), output del servidor. Sin log, no hay forensics cuando un toxic flow se ejecuta.
7. Auditoría periódica del inventario. Scan de configs en repos internos (GitGuardian-style). El baseline que el operador establece este trimestre cambia el siguiente — paquetes que se actualizan, descripciones que cambian, nuevos servidores que aparecen.

El programa es del mismo orden que el SaaS posture management que las organizaciones empezaron a montar en 2022-2023. La diferencia es que el catálogo está en estadio temprano y el blast radius es el escritorio de cada developer con un cliente registrado.

Cierre

Dieciséis meses después del primer paper. Dos revisiones del spec. Una OWASP MCP Top 10 v0.1. Doce CVEs públicos. Un benchmark académico con ASRs en los setentas. Un MCPwn explotado in the wild en Q1 2026. Un servidor postmark que infectó 300 organizaciones con una línea de código.

El spec ha hecho parte del trabajo que tocaba — autorización OAuth, elicitation, eliminación de batching, gobernanza formal. El host ha hecho menos del que se esperaba: el modelo de approval sigue siendo el modal del primer día, el sandboxing por servidor sigue sin ser default, la integridad de descripciones sigue sin estar en wire. El operador ha tenido que cubrir el hueco: gateways comerciales, trust scores, audit pipelines, scope policies. La industria que en abril 2025 estaba leyendo el paper de Invariant ahora vende productos para defenderse del paper de Invariant.

Lo que sigue cerca del año dos del spec: más CVEs en wrappers, más toxic flows en agentes con MCP múltiple, más supply-chain con malicious servers en registries comunitarios. El siguiente milestone, el primer spec breaking que cambie el wire para marcar origen de descripciones, o el primer regulator (AESIA, CNIL, NIST) que publique guidance específica sobre MCP en deployments, no tiene fecha al cierre de Q1. La próxima revisión del spec, la 2026-Hx, decidirá si la frase de noviembre 2024 sigue describiendo el protocolo en 2027.

Referencias

Spec y gobernanza

• MCP, Specification 2025-06-18 — OAuth Resource Servers, structured output, elicitation, eliminación de batching: https://modelcontextprotocol.io/specification/2025-06-18
• MCP, Specification 2025-11-25 changelog — OIDC discovery, incremental scope consent, OAuth CIMD, tasks, governance: https://modelcontextprotocol.io/specification/2025-11-25/changelog
• OWASP, MCP Top 10 v0.1 (Phase 3 — Beta) — Vandana Verma Sehgal, late 2025: https://owasp.org/www-project-mcp-top-10/

Paper académico

• Wang, Z. et al., MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers (AAAI 2026, arXiv:2508.14925, ago-2025): https://arxiv.org/abs/2508.14925

Incidentes públicos clave

• Invariant Labs, Tool Poisoning Attacks (TPA) — paper canónico (1-abr-2025): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
• Invariant Labs, WhatsApp MCP exploited (abr-2025): https://invariantlabs.ai/blog/whatsapp-mcp-exploited
• Invariant Labs, GitHub MCP exploited — toxic agent flow (may-2025): https://invariantlabs.ai/blog/mcp-github-vulnerability
• Invariant Labs, Toxic Flow Analysis — lethal trifecta formalizado: https://invariantlabs.ai/blog/toxic-flow-analysis
• GitGuardian, From Path Traversal to Supply Chain Compromise: Breaking MCP Server Hosting (oct-2025, Smithery): https://blog.gitguardian.com/breaking-mcp-server-hosting/
• Check Point Research, MCPoison — CVE-2025-54136 Cursor (ago-2025): https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/
• Koi Security, Postmark MCP — primer servidor malicioso in the wild (sep-2025): https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft
• Snyk, Malicious MCP Server on npm postmark-mcp Harvests Emails: https://snyk.io/blog/malicious-mcp-server-on-npm-postmark-mcp-harvests-emails/
• OX Security, The Mother of All AI Supply Chains (Q1-2026): https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/
• BleepingComputer, Critical Nginx UI auth bypass flaw now actively exploited in the wild — CVE-2026-33032 MCPwn (mar-2026): https://www.bleepingcomputer.com/news/security/critical-nginx-ui-auth-bypass-flaw-now-actively-exploited-in-the-wild/
• Authzed, A Timeline of Model Context Protocol (MCP) Security Breaches: https://authzed.com/blog/timeline-mcp-breaches

Stats del ecosistema

• AgentSeal, We Scanned 1,808 MCP Servers. 66% Had Security Findings: https://agentseal.org/blog/mcp-server-security-findings
• WorkOS, Securing agentic apps: How to vet the tools your AI agents depend on: https://workos.com/blog/mcp-supply-chain-security

Análisis seguimiento

• Simon Willison, Model Context Protocol has prompt injection security problems (abr-2025) — lethal trifecta: https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
• Simon Willison, The lethal trifecta for AI agents: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Posts propios precursores

• MCP tool poisoning — Invariant Labs (abr-2025): /mcp-tool-poisoning-invariant-labs
• Confused deputy revisitado: MCP y la versión protocolo del bug (nov-2024): /confused-deputy-mcp-agentes
• Markdown exfil — indirect injection (abr-2023): /markdown-exfil-indirect-injection