Más allá del tool poisoning: qué puede hacer realmente un servidor MCP remoto malicioso

¿Qué es esto?

El 21 de mayo de 2026 se publicó en Electronics (vol. 15, n.º 10, artículo 2214; recibido el 27 de abril de 2026) el artículo revisado por pares Beyond Tool Poisoning: Attack Surfaces of Malicious Remote MCP Servers Across LLM Platforms. El Model Context Protocol (MCP), presentado por Anthropic a finales de 2024, se ha convertido en el estándar de facto para conectar un host LLM con herramientas externas. Aquí se estudia su modo remoto: el usuario añade un servidor de terceros con una sola URL, lo que traslada de forma silenciosa buena parte de la superficie de ataque del host a una infraestructura operada por una parte anónima.

La mayoría del trabajo previo sobre seguridad de MCP se centró en el Tool Poisoning Attack (TPA): directivas ocultas en la descripción de una herramienta que secuestran al modelo en el momento del registro. Este artículo sostiene que la descripción es solo un rincón del espacio de amenaza y reorganiza el problema en torno a una pregunta más útil: ¿participa el host LLM en producir el resultado malicioso, o no?

Cómo funciona

Los autores dividen el comportamiento de un servidor malicioso en dos categorías y prueban cinco escenarios contra ChatGPT, Claude Desktop y Gemini CLI.

Categoría       Dónde se completa el ataque        Escenarios evaluados
-------------   -------------------------------   ----------------------------------------
LLM-passive     Dentro del servidor, usando solo    File Content Exfiltration
                los argumentos que despacha el       Email Content Exfiltration
                host. El razonamiento del LLM
                nunca ve el comportamiento
                malicioso.

LLM-active      El LLM es el canal de entrega.      Conditional URL Substitution
                El servidor induce al modelo a       Malicious Code Augmentation
                producir/retransmitir la carga,      Image Steganography
                vía la DESCRIPCIÓN de la herramienta
                (C1) o su RESPUESTA (C2).

Esta división importa porque la frontera de defensa decisiva difiere según la categoría. Para los ataques LLM-passive, la única defensa es el filtrado previo a la invocación de los datos que el host envía a la herramienta: una vez que los argumentos salen, el modelo no puede intervenir. Para los ataques LLM-active, la frontera es el razonamiento sobre el contenido del modelo: si trata una descripción de herramienta como autoritativa, y si valida una respuesta de herramienta antes de retransmitirla.

Cada resultado se mide con dos métricas: el Attack Success Rate (ASR) y un Self-Reporting Rate (SRR) que indica si un ataque exitoso sigue siendo visible para un usuario atento o se completa en silencio. La motivación no es hipotética: el artículo cita un incidente de septiembre de 2025 en el que un servidor MCP de Postmark no oficial (más de 1500 descargas semanales) fue modificado para poner silenciosamente en copia oculta (BCC) cada correo saliente a una dirección del atacante, sin ser detectado durante semanas.

Por qué importa

Destacan tres hallazgos, y cada uno desmonta una suposición cómoda.

Primero, el filtrado del host es muy incoherente entre proveedores. Ante la misma petición de envío de correo con una credencial, Claude Desktop mostró un ASR del 95 % frente al 50 % de ChatGPT (intervalos de confianza de Wilson al 95 % no superpuestos). ChatGPT tendía a rechazar de plano o a reemplazar las credenciales por [REDACTED] antes de reenviar; la misma petición pasaba sin problemas en otros hosts. «¿Es seguro?» no tiene una respuesta transferible: depende del host que se use.

Segundo, es el canal, no la técnica, lo que determina el éxito. Los ataques basados en descripción (C1) solo funcionaban de forma fiable en la sustitución de URL, mientras que los basados en respuesta (C2) —cargas ocultas en lo que la herramienta devuelve en tiempo de ejecución— tuvieron éxito en los tres escenarios LLM-active con un ASR ≥ 85 %. La salida de la herramienta en runtime es la superficie menos protegida, pese a que el tooling sigue escrutando sobre todo la descripción.

Tercero, y lo más preocupante en la práctica: los ataques exitosos casi nunca se revelan al usuario. El SRR fue del 0 % en todos los ataques LLM-passive y en la mayoría de las configuraciones LLM-active. La única excepción fue Claude, que reportó la carga insertada en el 100 % de los intentos exitosos de aumento de código basado en respuesta, prueba de que la transparencia es alcanzable, pero aún no sistemática.

Defensas

Ningún control único cubre esta superficie; el artículo aboga por una postura por capas, cada una respondiendo a una de las categorías anteriores.

• El filtrado del host previo a la invocación es la única línea contra la exfiltración LLM-passive. Elimine o enmascare los secretos (credenciales, tokens, datos personales) de los argumentos antes de enviarlos a cualquier herramienta remota, y prefiera la denegación por defecto de los datos salientes.
• La auditoría de respuestas a nivel del LLM es lo que detiene el canal de respuesta de alto ASR. Trate las respuestas de las herramientas como entradas no confiables —no solo las descripciones— y valide el contenido devuelto frente a la petición real del usuario antes de retransmitirlo.
• La transparencia de las salidas visibles para el usuario es la red de seguridad transversal. Muestre qué herramienta se ejecutó, qué datos recibió y cualquier modificación que el modelo haya hecho a su respuesta, para que un éxito silencioso (SRR 0 %) deje de serlo.
• A nivel operativo: trate los servidores MCP remotos como código de terceros que entra en su perímetro de confianza. Fije y audite los servidores en lugar de instalarlos por URL, vigile los cambios «rug-pull» del mantenedor y prefiera registros verificados a los agregadores abiertos.

Estas medidas coinciden con la orientación por capas que emerge de benchmarks de MCP como MCPTox y de panoramas de ecosistema más amplios como Beyond the Protocol.

Estado

Se trata de investigación académica publicada que evalúa hosts comerciales tal como están desplegados, no de un CVE de un solo proveedor. Los comportamientos son característicos del MCP remoto como patrón de diseño, más que de un fallo parcheable; por eso las mitigaciones anteriores son arquitectónicas. Fechas clave: MCP presentado a finales de 2024; incidente de Postmark en septiembre de 2025; artículo recibido el 27 de abril de 2026 y publicado el 21 de mayo de 2026. El comportamiento de filtrado por plataforma puede cambiar a medida que los proveedores actualicen sus hosts; la lección duradera es la disparidad entre plataformas.