- Los servidores MCP conectan la IA con sistemas críticos y operan con altos privilegios, lo que los convierte en objetivos prioritarios para atacantes.
- Han aparecido vectores específicos de ataque (envenenamiento de herramientas, rug-pull, RADE, suplantación y sombreado de servidores) y vulnerabilidades graves como CVE-2025-6514.
- Incidentes como el servidor Postmark MCP malicioso demuestran que la cadena de suministro de paquetes npm puede causar filtraciones masivas de datos sin señales evidentes.
- Plataformas como Microsoft Defender y Sentinel empiezan a ofrecer visibilidad, control y cumplimiento sobre servidores MCP y proveedores de modelos de IA.
La adopción de servidores MCP y agentes de IA está creciendo a un ritmo brutal en empresas de todo tipo, desde startups hasta grandes corporaciones. Esta integración tan profunda con sistemas de negocio críticos convierte a los servidores MCP en un objetivo jugoso para atacantes, y los últimos incidentes demuestran que ya no hablamos de teoría, sino de casos reales que están ocurriendo en entornos de producción.
En este artículo vamos a desgranar con todo detalle qué está pasando con los servidores MCP comprometidos, qué riesgos suponen para la seguridad, qué ataques se han visto “en la naturaleza” y qué medidas están proponiendo tanto la industria como proveedores como Microsoft para defenderse. Verás que no se trata solo de vulnerabilidades técnicas clásicas, sino también de problemas de cadena de suministro, confianza ciega en paquetes de terceros y falta de visibilidad sobre dónde y cómo se está usando la IA dentro de la organización.
Qué es un servidor MCP y por qué se ha vuelto tan crítico
Un servidor MCP (Model Context Protocol) actúa como puente entre modelos de IA y sistemas empresariales como bases de datos, correo electrónico o plataformas internas. En lugar de que el modelo trabaje “a ciegas”, el servidor MCP le da contexto en tiempo real: acceso a tablas, APIs, herramientas internas o flujos de trabajo.
En la práctica, estos servidores permiten que la IA ejecute tareas automatizadas complejas, como responder correos, consultar tickets, extraer datos de facturas o lanzar consultas SQL contra un lago de datos. Es decir, dejan de ser simples generadores de texto para convertirse en piezas que toman acciones reales sobre la infraestructura de la empresa.
El problema es que, para poder hacer todo eso, los servidores MCP suelen operar con permisos muy elevados: acceso a correos, bases de datos, APIs internas y sistemas de producción. Como señalan expertos en seguridad como Idan Dardikman (Koi Security), estos servidores heredan prácticamente los mismos privilegios que los asistentes de IA, pero sin su visibilidad ni controles.
Para colmo, muchos servidores MCP no aparecen en inventarios de activos, no se incluyen en procesos formales de evaluación de proveedores y, en general, se escapan de los controles clásicos de seguridad y cumplimiento. Esto crea un escenario ideal para la “shadow AI”, es decir, el uso de herramientas de IA no autorizadas o mal gobernadas dentro de la compañía.
Los proveedores de modelos de IA basados en SaaS, accesibles mediante APIs, completan el puzzle: permiten incorporar IA avanzada sin infraestructuras complejas, pero a cambio aumentan la superficie de exposición de datos sensibles y la dependencia de componentes externos.
Principales vectores de ataque contra servidores MCP
La comunidad de seguridad ha empezado a catalogar los vectores de ataque específicos de MCP, que combinan técnicas conocidas con escenarios nuevos propios de agentes de IA. Estos cinco vectores se consideran especialmente peligrosos por su sencillez y el impacto potencial que tienen sobre datos y sistemas.
En primer lugar está el envenenamiento de herramientas o tool poisoning. El atacante publica o distribuye una herramienta para MCP que, por nombre y descripción, parece totalmente inocua (por ejemplo, una simple calculadora). Sin embargo, por dentro incluye código malicioso preparado para borrar archivos, exfiltrar información o modificar configuraciones cuando el agente la ejecuta.
El segundo vector es el de las actualizaciones tipo “rug-pull”. Una herramienta o servidor MCP empieza siendo legítimo y seguro; los equipos la prueban, la validan y la integran en sus flujos. Días o semanas más tarde, se publica una actualización que introduce código malicioso. Como la herramienta ya está “de confianza” y los agentes la usan a diario, nadie se fija en que la nueva versión ahora roba datos o ejecuta acciones destructivas.
El tercer enfoque se conoce como engaño del agente de recuperación (Recovery Agent Deception, RADE). Aquí el atacante esconde instrucciones de MCP en documentos públicos (por ejemplo, en un repositorio o una web). Un sistema de recuperación de información asociado al agente ingiere ese contenido, y el agente, al interpretarlo, termina ejecutando órdenes que nunca debió obedecer, todo ello sin que el usuario sea consciente.
En cuarto lugar aparece la suplantación de servidores MCP. Un atacante monta un servidor que imita el nombre, lista de herramientas y comportamiento superficial de un servicio conocido (tipo GitHub, Jira u otros). El cliente MCP del usuario se conecta creyendo que habla con el servidor legítimo, pero en realidad todas las llamadas y datos pasan por el servidor fraudulento, que puede registrar, manipular o redirigir la información.
El quinto vector clave es el sombreado entre servidores o server shadowing. En entornos donde hay múltiples servidores MCP conectados entre sí, basta con que uno esté comprometido para que pueda interceptar, modificar o anular las peticiones destinadas a otro servidor confiable. Este tipo de ataque es especialmente sutil, porque se apoya en la confianza preexistente entre componentes internos de la arquitectura.
Vulnerabilidad crítica en mcp‑remote y ejecución remota de código
Más allá de estos vectores generales, ha salido a la luz una vulnerabilidad crítica en un componente concreto del ecosistema MCP: mcp‑remote, una utilidad open-source que funciona como proxy entre clientes MCP y servidores remotos. Su objetivo es facilitar la conexión a servidores MCP de terceros, pero un fallo en su diseño ha abierto la puerta a ataques de ejecución remota de código (RCE).
Esta vulnerabilidad, identificada como CVE-2025-6514 con una puntuación CVSS 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), permite la inyección de comandos del sistema operativo cuando mcp-remote se conecta a un servidor MCP malicioso o no confiable. El impacto potencial es el compromiso completo del equipo donde se ejecuta el cliente.
El problema se manifiesta durante la fase de autorización OAuth. Un servidor MCP malicioso puede enviar, en el campo authorization_endpoint, una URL especialmente diseñada. Debido a cómo Node.js procesa esa URL y a cómo la librería open la maneja, se acaba forzando la ejecución de comandos arbitrarios en el sistema donde corre mcp-remote.
En sistemas Windows, este abuso se traduce en ejecución de comandos de consola con parámetros totalmente controlados por el atacante. En macOS y Linux la explotación se centra más en la apertura y ejecución de archivos arbitrarios, con algunas limitaciones adicionales, pero igualmente peligrosa si se encadena con otras técnicas.
Las versiones afectadas abarcan desde la 0.0.5 hasta la 0.1.15 de mcp‑remote, lo que cubre prácticamente todas las instalaciones activas durante el periodo en el que se descubrió el fallo. No se han documentado medidas de mitigación completa (“workarounds”) más allá de limitar el uso, por lo que el consejo principal es claro.
Las recomendaciones oficiales pasan por actualizar a la última versión corregida de mcp‑remote y evitar conexiones con servidores MCP que no sean de total confianza, asegurando además que las comunicaciones se realizan mediante HTTPS para reducir riesgos adicionales de manipulación en tránsito.
El caso Postmark MCP: un servidor malicioso en plena cadena de suministro
Uno de los incidentes más reveladores hasta la fecha es el del servidor malicioso “Postmark MCP Server” distribuido a través de npm. Este ejemplo ilustra perfectamente cómo un pequeño cambio en un paquete muy usado puede derivar en una filtración masiva y silenciosa de información sensible.
El atacante copió el código legítimo del repositorio oficial de GitHub del servidor MCP de Postmark y, a partir de ahí, introdujo una única línea maliciosa que reenviaba todos los correos procesados a un servidor controlado por él (giftshop.club). Después publicó este paquete modificado en npm bajo el mismo nombre, aprovechando la confianza en la marca y en el ecosistema.
Se estima que el paquete se descargaba alrededor de 1.500 veces por semana y se integró en cientos de flujos de trabajo de desarrolladores. Lo más preocupante es que el servidor malicioso funcionaba aparentemente igual que el original: los correos se procesaban, las integraciones seguían respondiendo y, en apariencia, nada estaba roto.
Según los análisis de Koi Security, el servidor adulterado llegó a copiar entre 3.000 y 15.000 correos diarios, incluyendo facturas, comunicaciones internas y documentación confidencial. Todo ello pasaba completamente desapercibido para soluciones tradicionales como gateways de correo o sistemas DLP, ya que el tráfico se producía dentro de flujos aparentemente legítimos.
Este caso deja claro que el riesgo ya no está solo en vulnerabilidades clásicas de infraestructura, sino en la cadena de suministro digital: paquetes npm, dependencias de terceros y servidores MCP distribuidos desde repositorios públicos. Un pequeño cambio no auditado puede comprometer operaciones críticas sin dejar señales evidentes.
Como advertía uno de los investigadores implicados, en la práctica “se le dio al servidor las llaves del sistema y se le pidió que ejecutara código con todos los permisos disponibles”, confiando ciegamente en que ese paquete era seguro solo por su nombre y popularidad.
Recomendaciones específicas para empresas y desarrolladores
A raíz del incidente de Postmark MCP y de otros hallazgos, expertos en seguridad han publicado una serie de medidas urgentes y buenas prácticas orientadas tanto a equipos técnicos como a responsables de seguridad. El objetivo es reducir el riesgo de que un servidor MCP o un paquete relacionado se convierta en un vector de fuga de datos.
En primer lugar, se ha instado a eliminar inmediatamente la versión 1.0.16 del paquete “Postmark MCP Server” y cualquier otra versión que se haya identificado como comprometida. Esta limpieza debe ir acompañada de una revisión de logs y flujos de trabajo que hayan dependido de ese servidor.
En segundo lugar, se recomienda rotar todas las credenciales que pudieran haberse visto expuestas a través de ese servidor MCP: claves de API, tokens de acceso, credenciales de correo y cualquier otra secret vinculada a los sistemas con los que el servidor interactuaba.
Otra medida clave es auditar todos los servidores MCP en uso dentro de la organización, verificando que provienen de repositorios oficiales y confiables, y comprobando la integridad de su código fuente. Esto implica revisar tanto servidores desplegados en producción como prototipos o entornos de prueba donde la seguridad suele relajarse.
Los equipos de desarrollo deberían acostumbrarse a revisar el código fuente de cada paquete que se integre en flujos de trabajo sensibles y monitorizar activamente los cambios entre versiones. No basta con fiarse de la popularidad de un paquete; hay que vigilar los diffs, las nuevas dependencias y el comportamiento observador en ejecución.
Por último, las organizaciones deberían implementar controles específicos para servidores MCP: inventario de activos, evaluación de riesgos por proveedor, políticas de uso, monitorización de tráfico y alertas sobre patrones anómalos de acceso a datos. Esta capa de gobierno es esencial para reducir la “IA en la sombra” y evitar que servidores no autorizados se cuelen por la puerta de atrás.
La respuesta de Microsoft: visibilidad y control sobre MCP y proveedores de modelos
Grandes proveedores de seguridad están empezando a adaptar sus plataformas para cubrir de forma explícita los riesgos de MCP y de servicios de modelos de IA. Microsoft, en particular, ha anunciado que Microsoft Defender amplía sus capacidades para proteger el uso de MCP y proveedores de modelos de IA en entornos empresariales, tanto en nubes propias como en infraestructuras multicloud.
Entre las mejoras recientes, Defender for Cloud ahora ofrece visibilidad sobre contenedores que ejecutan MCP en AWS, GCP y Azure, identificando configuraciones inseguras, vulnerabilidades en aplicaciones y agentes de IA que utilizan estos servidores. Además, se ha añadido soporte específico en Microsoft Defender for Cloud Apps para descubrir y gestionar no solo aplicaciones de IA generativa, sino también servidores MCP y proveedores de modelos.
El catálogo de aplicaciones en la nube de Microsoft, que ya incluía más de 35.000 apps detectables con parámetros de riesgo detallados, se ha ampliado con nuevas categorías dedicadas a proveedores de modelos de IA y servidores MCP. Esto permite evaluar su postura de riesgo en función de prácticas de manejo de datos, métodos de autenticación, ámbitos de integración y otros factores clave.
Además, Microsoft tiene como objetivo ofrecer información de seguridad más rica sobre estos servicios, apoyándose en feedback de clientes para mejorar los análisis de riesgo y las recomendaciones de mitigación. La idea es equipar a los equipos de seguridad con métricas y contexto suficientes para tomar decisiones sobre qué servicios autorizar, restringir o bloquear.
Si una organización aloja su propio servidor MCP y utiliza Defender for Cloud, la funcionalidad de Gestión de Postura de Seguridad de IA ayuda a descubrir todos los servidores MCP desplegados en entornos multicloud, detectar errores de configuración y vulnerabilidades, y priorizar acciones correctivas mediante análisis de vías de ataque.
Microsoft Sentinel y su servidor MCP orientado a seguridad
Más allá de la capa defensiva, Microsoft también está construyendo servidores MCP propios orientados a casos de uso de seguridad, como es el caso del servidor MCP de Microsoft Sentinel. Este componente se ajusta a los principios de IA responsable de la compañía y busca facilitar escenarios avanzados de detección y respuesta.
El servidor MCP de Microsoft Sentinel está diseñado como un protocolo del lado servidor que expone herramientas especializadas, como search_tables, para realizar búsqueda semántica entre tablas del lago de datos del propio Sentinel. De este modo, agentes y herramientas pueden formular consultas en lenguaje natural y obtener datos tabulares relevantes sin necesidad de dominar el esquema interno.
La interfaz unificada del servidor MCP de Sentinel permite a los agentes descubrir tablas relevantes según la consulta en lenguaje natural, recuperar metadatos y contexto para apoyar investigaciones, y realizar análisis de entidades para emitir veredictos y estudiar amenazas. Todo ello se integra con flujos de trabajo de búsqueda de amenazas, respuesta a incidentes e investigaciones forenses.
Estas capacidades están pensadas para equipos de seguridad como analistas, investigadores y cazadores de amenazas, que necesitan navegar por grandes volúmenes de datos sin perder tiempo en traducciones manuales entre lenguaje natural y consultas complejas.
El uso previsto del protocolo es muy específico: flujos de trabajo centrados en la seguridad que requieren acceso a tablas estructuradas del lago de datos de Sentinel. No está pensado como asistente de IA de propósito general, sino como un mecanismo optimizado para búsqueda semántica y análisis de seguridad en ese entorno concreto.
Entre sus limitaciones destaca que es estrictamente de dominio de seguridad: consultas fuera del ámbito de búsqueda de tablas pueden producir respuestas vacías o poco útiles. Además, los resultados dependen del estado del lago de datos; si los datos están desactualizados o incompletos, las respuestas serán igualmente limitadas. Por último, el rendimiento y alcance dependen de que las herramientas que usan el protocolo estén correctamente configuradas con plugins y orígenes de datos adecuados.
IA responsable, cumplimiento normativo y confianza en MCP
Microsoft enfatiza que el desarrollo del servidor MCP de Sentinel y de sus soluciones relacionadas se realiza bajo un marco de IA generativa responsable por diseño, apoyado en principios como equidad, fiabilidad, seguridad, privacidad, inclusión, transparencia y responsabilidad. Esta filosofía pretende reforzar la confianza de clientes y reguladores en la tecnología que se está desplegando.
La compañía asegura que el servidor MCP de Sentinel se alinea con sus principios de IA responsable y se está desarrollando en estrecha colaboración con el equipo de Security Copilot, con la intención de mantener siempre a la persona como elemento central del proceso. Esto incluye diseñar experiencias que mitiguen errores y eviten usos indebidos.
Entre las medidas de seguridad mencionadas se encuentran mecanismos de anotación de contenido potencialmente dañino, supervisión operativa continua y otros controles de seguridad que buscan reducir la probabilidad de abuso o respuestas perjudiciales. Además, el programa de acceso anticipado funciona solo mediante invitación, lo que permite recoger comentarios de un grupo controlado de usuarios antes de una disponibilidad general.
En cuanto al marco regulatorio, Microsoft afirma estar comprometida con el cumplimiento de la Ley de IA de la Unión Europea, apoyándose en años de trabajo en estándares internos de IA responsable y gobernanza. El objetivo es que tanto sus propios productos como las soluciones que construyen los clientes con ellos puedan adaptarse al nuevo marco legal europeo.
De hecho, la compañía está trabajando con autoridades europeas para definir prácticas de aplicación efectivas y ha publicado recursos informativos sobre la Ley de IA de la UE, explicando cómo se traduce en la práctica para desarrolladores, empresas y proveedores de servicios.
Este enfoque de cumplimiento y responsabilidad es clave en un entorno donde, como se ha visto con los servidores MCP comprometidos, la confianza no puede basarse únicamente en la reputación del proveedor o en la popularidad de un paquete, sino en auditorías continuas, controles técnicos y marcos normativos que obliguen a elevar el listón de seguridad.
Todo el ecosistema MCP se encuentra en un punto de inflexión: por un lado, habilita una productividad enorme al permitir que la IA actúe con contexto real sobre sistemas empresariales; por otro, abre nuevas rutas de ataque basadas en permisos de alto nivel, cadenas de suministro de software y uso no gobernado de herramientas de IA. A partir de ahora, cualquier organización que quiera aprovechar estos beneficios tendrá que tomarse muy en serio la visibilidad, el inventario de servidores MCP, la auditoría de paquetes y la adopción de plataformas de seguridad capaces de detectar y frenar comportamientos anómalos antes de que un simple servidor “inofensivo” acabe llevándose consigo miles de correos, bases de datos enteras o el control de sistemas críticos.
