Servidores MCP maliciosos y seguridad del correo electrónico: la nueva amenaza para la cadena de suministro
por
Última actualización: Tiempo de lectura: 9 minutos
Puntos clave
- Los atacantes están utilizando paquetes npm con nombres falsificados por errores ortográficos para engañar a los desarrolladores y que instalen servidores falsos del Protocolo de Contexto de Modelo (MCP).
- Estos servidores maliciosos heredan claves API corporativas preautorizadas y envían de forma silenciosa, en copia oculta, datos confidenciales salientes a dominios controlados por los atacantes.
- Dado que estos correos electrónicos pasan por tu infraestructura legítima, los filtros tradicionales como SPF y DKIM los dejan pasar automáticamente.
- Para subsanar esta deficiencia, es necesario llevar a cabo una auditoría rigurosa de las dependencias de las aplicaciones, limitar el alcance de las API al mínimo necesario y supervisar de forma continua el volumen agregado de DMARC.
En septiembre de 2025, una sola línea de código oculto en una biblioteca npm de código abierto echó por tierra nuestras suposiciones sobre la seguridad de la cadena de suministro. Esto puso de relieve la seguridad maliciosa del correo electrónico de los servidores MCP como una nueva y peligrosa clase de amenaza.
El paquete, denominado «postmark-mcp», pasó más de una semana reenviando entre 3 000 y 15 000 correos electrónicos corporativos al día a un atacante. No se trataba de ningún exploit de día cero llamativo, sino simplemente de una regla básica y oculta de copia oculta (CCO) ejecutada con permisos administrativos completos. Las consecuencias fueron devastadoras: se filtraron contraseñas, facturas internas, datos de clientes y tokens de autenticación activos.
Este es el primer caso documentado de una intrusión maliciosa en un servidor MCP en un entorno real. A medida que los agentes de IA autónomos se extienden por los flujos de trabajo de las empresas, están dejando al descubierto un enorme punto ciego. Las defensas tradicionales como SPF, DKIM y DMARC se diseñaron para una era de enrutamiento de correo predecible y gestionado por personas. El paradigma del Protocolo de Contexto de Modelo (MCP) altera por completo esa postura, introduciendo una capa de amenazas internas que los filtros perimetrales tradicionales simplemente no pueden detectar.
Qué ocurrió: el incidente del matasellos «mcp»
Postmark (gestionado por ActiveCampaign) es un popular servicio de correo electrónico transaccional que utilizan miles de empresas para enviar notificaciones automáticas esenciales, como restablecimientos de contraseñas y confirmaciones de pedidos. Para dar respuesta al auge de la IA generativa, se ha lanzado un repositorio oficial de código abierto en GitHub que permite a los desarrolladores conectar el asistente de IA Claude, de Anthropic, directamente a la infraestructura de Postmark a través del Protocolo de Contexto de Modelos.
Al ver una brecha fácil de explotar, un actor malintencionado publicó un paquete con un nombre muy similar, llamado «postmark-mcp». No se trataba de un simple error de tipografía, sino de una coincidencia exacta del nombre, diseñada para atrapar a los desarrolladores que buscaban una instalación rápida de npm.
Una estrategia a largo plazo: generar confianza
El atacante llevó a cabo una estrategia a largo plazo muy calculada. A lo largo de quince versiones consecutivas (desde la 1.0.0 hasta la 1.0.15), el paquete funcionó sin problemas. Reproducía fielmente el código del repositorio oficial, ejecutaba las llamadas a la API a la perfección y no generaba ninguna alerta. Esto le permitió eludir con facilidad los controles automatizados del entorno de pruebas y ganarse la confianza inicial de los sistemas de seguimiento de seguridad.
Activación de la carga útil
El 17 de septiembre de 2025 se produjeron daños importantes con la versión 1.0.16. En lo más profundo del archivo index.js, en la línea 231, el editor añadió una línea de código. Este cambio añadía una dirección BCC oculta a cada mensaje de correo electrónico que pasaba por el servidor y redirigía copias a un dominio controlado por el atacante [giftshop.club].
Dado que este módulo se encontraba dentro de la capa de aplicación validada, ya disponía de acceso autorizado a claves API activas. El ataque no requirió ninguna escalada de privilegios sofisticada. Funcionó porque el código se ejecutaba dentro de un flujo de trabajo corporativo de confianza. La fuga de datos continuó hasta el 25 de septiembre de 2025, cuando el motor de riesgos de Koi Security detectó patrones de comportamiento anómalos procedentes de la biblioteca.
El impacto
Las auditorías posteriores al incidente realizadas por Koi Security y Snyk revelaron que el paquete había acumulado unas 1.643 descargas, lo que se traducía en unas 1.500 instalaciones activas semanales que filtraban datos a diario.
Cuando se descubrió el problema, el editor eliminó el paquete de npm. Pero aquí está el verdadero quebradero de cabeza: retirar un paquete de un registro público no lo elimina de los entornos activos. Cualquier clúster en la nube o canalización de contenedores activos que ejecutaran la versión 1.0.16 siguieron filtrando datos hasta que los equipos lo localizaron y lo eliminaron manualmente. Postmark emitió rápidamente un comunicado en el que aclaraba que no había desarrollado, autorizado ni mantenido el paquete. Dado que se trataba de una puerta trasera de comportamiento y no de un fallo de código, no se le asignó ningún identificador formal de Vulnerabilidades y Exposiciones Comunes (CVE), lo que deja tras de sí una huella única y sin verificar de un ataque a la cadena de suministro del servidor MCP.
Si crees que tu equipo ha utilizado este paquete en algún momento, trátalo como un incidente activo: desinstálalo inmediatamente de todos los entornos, renueva todas las credenciales y claves API que hayan pasado por él, y revisa tus registros de correo en busca de tráfico en copia oculta (BCC) dirigido al dominio señalado. También conviene revisar el resto de la cuenta del editor; el mismo autor mantenía aproximadamente otros 31 paquetes, cualquiera de los cuales podría entrañar el mismo riesgo.
¿Por qué los servidores MCP son un objetivo tan atractivo para los ataques de correo electrónico?
El Protocolo de Contexto de Modelos (MCP) se está convirtiendo rápidamente en el marco de integración estándar para la IA empresarial. Gartner prevé que, para finales de 2026, el 75 % de los proveedores de pasarelas API habrán integrado conjuntos de herramientas MCP nativas para gestionar la seguridad del correo electrónico basada en IA autónoma.
¿En qué consiste exactamente una integración del Protocolo de Contexto de Modelos (MCP)? Piensa en un servidor MCP como un puente API seguro que conecta un asistente de IA (como Claude) con repositorios de datos externos, entornos de desarrollo y herramientas de terceros. En lugar de gestionar una maraña de API personalizadas, un agente de IA utiliza este protocolo unificado para consultar bases de datos, revisar sistemas CRM u organizar flujos de correo electrónico de forma autónoma.
La vulnerabilidad fundamental: la confianza total
Para que un servidor MCP sea útil, necesita permisos operativos amplios y a largo plazo. Cuando conectas un agente de IA a una pasarela de correo electrónico para automatizar la programación o la atención al cliente, le concedes acceso completo de lectura y escritura. Actúa como un empleado con plenos derechos de delegación.
Como señaló Idan Dardikman, director técnico de Koi Security, las organizaciones están, en esencia, concediendo permisos administrativos de «modo dios» a herramientas de backend creadas por desarrolladores externos no verificados y en los que no se confía.
A diferencia de los ataques tradicionales a la cadena de suministro de software (como el de SolarWinds), que se dirigen a la infraestructura profunda, los riesgos relacionados con los servidores MCP de terceros no requieren ningún tipo de intrusión en la infraestructura. Los atacantes solo tienen que engañarte para que instales el módulo, y el agente de IA lo ejecuta de forma autónoma. Dado que no hay ningún ser humano que supervise el flujo de trabajo automatizado, una biblioteca comprometida puede sustraer datos confidenciales durante días sin que se active ninguna señal de alarma.
La brecha en la autenticación del correo electrónico: lo que DMARC puede y no puede proteger
Mientras los equipos de gestión de riesgos se apresuran a defenderse de estas amenazas de correo electrónico que atacan la cadena de suministro mediante IA, muchos dan por sentado que protocolos como SPF, DKIM y DMARC frenarán la hemorragia. Sin embargo, debemos analizar detenidamente qué es lo que realmente abordan estos controles y dónde se encuentran las lagunas.
Lo que se pretendía evitar con DMARC, SPF y DKIM
El conjunto básico de SPF, DKIM y DMARC se diseñó para impedir la suplantación de dominios y evitar que personas malintencionadas lleven a cabo campañas de suplantación de correo electrónico o de BEC utilizando la identidad de su marca.
- SPF comprueba si la dirección IP del servidor de correo remitente está autorizada en tus registros DNS.
- DKIM añade una firma digital única al encabezado para demostrar que el mensaje no ha sido alterado durante el tránsito.
- DMARC los integra, imponiendo normas sobre cómo deben gestionar los servidores receptores los errores.
En el ataque «postmark-mcp», estos controles no se eludieron, sino que resultaron totalmente irrelevantes. Dado que el paquete malicioso estaba integrado en una aplicación corporativa legítima, utilizaba claves API válidas para enrutar los mensajes a través de los servidores autorizados de Postmark. Todos los correos electrónicos robados llevaban una firma DKIM impecable y superaban perfectamente las comprobaciones SPF. Aquí hay una amarga ironía: esa firma DKIM válida incluso ayudó al propio servidor receptor del atacante a confirmar que los mensajes robados eran auténticos.
Cuándo la autenticación del correo electrónico resulta parcialmente útil
| Componente del protocolo | Capacidad frente a servidores MCP maliciosos | Limitación |
|---|---|---|
| SPF y DKIM | Comprueba la validez de la infraestructura. | Se aprueba sin problemas, ya que el ataque se origina en la capa de aplicación autorizada. |
| Aplicación de DMARC (p=rechazar) | Evita la suplantación de dominios externos. | No se puede impedir que una aplicación interna válida ejecute una regla BCC o divulgue datos directamente. |
| Informes DMARC (RUA / RUF) | Ofrece una visión detallada de los volúmenes de envíos salientes y de las fuentes de terceros. | Requiere una supervisión continua y automatizada, así como un análisis del comportamiento, para detectar anomalías. |
Lo que la autenticación de correo electrónico puede y no puede hacer en este caso
DMARC, SPF y DKIM se crearon para combatir la suplantación de identidad, no la filtración de datos por parte de empleados
| No se puede bloquear | Puedo revelar | Puede contener |
|---|---|---|
| El servidor malicioso utiliza una clave API legítima, por lo que el resultado «SPF & DKIM PASS» p=reject no puede impedir que una aplicación interna válida añada un destinatario en «CC oculto» y filtre datos directamente. | Los informes agregados de RUA muestran todas las fuentes de envío de tu dominio Un aumento repentino en el volumen de transacciones salientes es la señal de alarma | El cambio a «p=reject» actúa como medida de protección frente a las repercusiones Impide que los atacantes utilicen el contenido robado para suplantar tu dominio en campañas de phishing posteriores |
El poder de los informes DMARC para mejorar la visibilidad
Aunque no impedirá la inyección inicial de código, una configuración sólida de autenticación del correo electrónico ofrece una visibilidad fundamental. Esto se traduce en informes DMARC detallados (RUA/RUF).
Cuando están correctamente configurados, estos registros te proporcionan un mapa detallado de todas las direcciones IP y los servicios de envío activos en tu dominio. Los informes agregados (RUA) resumen los volúmenes de envío por origen, mientras que los informes de fallos (RUF) recogen detalles sobre fallos concretos. Si tu equipo de SecOps audita continuamente estos flujos, podrá detectar picos repentinos e inexplicables en los volúmenes de transacciones salientes. El seguimiento de esas anomalías actúa como un detector de humo, indicando que una integración está filtrando datos.
Establecer un mecanismo de protección con una aplicación estricta
Cambiar la configuración de tu dominio a una política DMARC estricta con el valor «p=reject» ofrece una protección fundamental contra las consecuencias secundarias. Aunque no impedirá que un servidor MCP interno envíe datos en copia oculta (BCC), sí evita que los atacantes utilicen lo que roban con fines maliciosos. Una política de rechazo impide que los actores maliciosos utilicen facturas filtradas o datos de clientes para lanzar campañas de phishing suplantadas y altamente dirigidas contra tus clientes y socios utilizando tu propio dominio.
La verdadera brecha: la higiene de las credenciales y los permisos
En esencia, esta brecha de seguridad se debió a un fallo en la gestión de identidades y accesos, y no a un problema con el protocolo de autenticación. El ataque tuvo éxito porque un programa no verificado tenía acceso a una clave API legítima con amplios privilegios.
Tu principal línea de defensa en este caso es la auditoría de las dependencias del código y el buen uso de las credenciales. Sin embargo, implementar herramientas de IA autónomas sin una capa de visibilidad activa te deja completamente a ciegas. La supervisión continua de DMARC crea la red de seguridad activa necesaria para detectar las anomalías de comportamiento que indican un ataque en curso.
Cómo proteger a tu organización de los ataques maliciosos por correo electrónico a través de MCP
La seguridad del correo electrónico de un servidor MCP malicioso requiere medidas operativas como las que se indican a continuación:
1. Analiza la huella de tu servidor MCP
No se puede proteger lo que no se supervisa. Elabora un inventario detallado de todas las integraciones, complementos o puntos de conexión activos vinculados a tu configuración de correo electrónico.
- Comprueba si la integración procede de un repositorio oficial de un proveedor o de un paquete de la comunidad no verificado en npm o PyPI.
- Registra de forma explícita qué datos y puntos finales puede acceder cada integración.
- Utiliza herramientas de seguridad de código abierto, como mcp-scan, para identificar y analizar tu entorno en busca de anomalías en el comportamiento.
2. Aplicar el principio del mínimo privilegio a las integraciones de correo electrónico con IA
Dejen de conceder acceso administrativo sin restricciones a las herramientas automatizadas.
- Limita las claves de la API para que solo permitan las acciones estrictamente necesarias (por ejemplo, el envío de notificaciones), al tiempo que bloquea explícitamente el acceso completo de lectura y escritura al buzón.
- Aplica calendarios estrictos de rotación de claves API y revoca las credenciales de inmediato si una dependencia genera una alerta.
- Utilice un cortafuegos y políticas de seguridad de red para restringir los destinos de salida desde los servidores MCP y permita únicamente los puntos finales de API de correo electrónico corporativo conocidos.
3. Activar los informes DMARC y supervisar si hay anomalías
Si no estás procesando activamente los datos agregados de DMARC, tienes un enorme punto ciego operativo. La implementación de un analizador de DMARC específico proporciona a tu equipo una visibilidad continua, lo que te permite realizar un seguimiento de los flujos de datos, establecer valores de referencia de volumen y recibir alertas ante picos repentinos de tráfico transaccional saliente antes de que se produzcan daños graves.
4. Aplicar DMARC con el valor p=reject
Dejar tu dominio con una configuración débil de «p=none» no ofrece ninguna protección real. Pasar a un nivel de aplicación estricto de «p=reject» garantiza que, incluso si un atacante logra sustraer el contenido del correo a través de una integración comprometida, nunca podrá utilizar esa información robada para lanzar campañas fraudulentas que imiten el dominio oficial de tu marca.
5. Comprobar los servidores MCP antes de la implementación
Trata cualquier módulo de servidor MCP con el mismo rigor que cualquier otro componente privilegiado de la infraestructura empresarial. Comprueba el historial del editor, compara los paquetes con la documentación oficial del proveedor y revisa el código fuente subyacente antes de implementarlo en producción.
Para minimizar los riesgos, evita los paquetes comunitarios sin modificar y opta por integraciones certificadas y verificadas por el proveedor. Para los equipos que implementan la automatización, elegir opciones de proveedores verificados, como el servidor MCP de PowerDMARC, garantiza una capa de integración segura y autenticada, diseñada específicamente para garantizar la seguridad de las operaciones empresariales.
Una visión más amplia: la seguridad MCP marcará la próxima etapa de las amenazas al correo electrónico
La vulnerabilidad de la biblioteca postmark-mcp fue, por su diseño, de baja complejidad: un solo desarrollador, un sencillo truco de coincidencia de nombres y una única línea de código oculto. Sin embargo, provocó una filtración generalizada de datos. A medida que las empresas adopten rápidamente herramientas de IA autónomas y el MCP se convierta en un estándar en las arquitecturas de software, los grupos de ciberdelincuentes lanzarán inevitablemente operaciones mucho más avanzadas.
Los equipos de seguridad deben prepararse para hacer frente a varios vectores de amenazas emergentes:
- Inyección indirecta de comandos: los atacantes envían correos electrónicos maliciosos diseñados para manipular a un agente de IA que lee la bandeja de entrada y engañarlo para que desvíe datos confidenciales o filtre claves internas.
- Herramientas de flujo de trabajo maliciosas: los atacantes están publicando herramientas de productividad basadas en IA que parecen útiles, pero que, en realidad, recopilan credenciales y tokens de forma encubierta en segundo plano.
- Imitaciones de alto valor: sofisticadas campañas de typosquatting dirigidas a integraciones de CRM, RR. HH. y finanzas para empresas en redes de paquetes para desarrolladores.
El correo electrónico es bastante vulnerable, ya que se encuentra en la encrucijada entre la comunicación corporativa, la verificación de identidad (restablecimiento de contraseñas) y los datos empresariales críticos. Los servidores MCP que integran la IA en esta infraestructura tienen acceso a los tres.
Conclusión
El panorama de las amenazas por correo electrónico ha evolucionado mucho más allá del simple phishing externo. El incidente de Postmark-MCP demuestra que las organizaciones se enfrentan ahora a amenazas en la cadena de suministro basadas en la inteligencia artificial que operan de forma silenciosa dentro de entornos internos de confianza. Estos ataques de integración aprovechan credenciales válidas para eludir los filtros tradicionales, y es precisamente por eso que la seguridad del correo electrónico frente a servidores MCP maliciosos debe figurar ahora en la agenda de todo director de seguridad de la información (CISO).
Para proteger su empresa es necesario encontrar un equilibrio entre unos controles de permisos estrictos y un seguimiento continuo de los datos. La combinación de una política de cumplimiento rigurosa con informes detallados le permite detectar volúmenes de envío inusuales y detectar integraciones no autorizadas antes de que se produzca una pérdida definitiva de datos.
No dejes tus sistemas automatizados sin supervisar. Protege tu dominio hoy mismo contra las amenazas ocultas en la capa de aplicaciones. Identifica todas las fuentes que envían correos electrónicos en nombre de tu dominio; empieza a supervisar con el DMARC Analyzer de PowerDMARC.
Preguntas frecuentes
Un momento, si mis correos electrónicos superan las comprobaciones de SPF y DKIM, ¿cómo puede ser eso un fallo de seguridad?
Porque la llamada proviene del interior de la casa. El paquete malicioso no está suplantando tu dominio desde un servidor malintencionado cualquiera. Se encuentra justo dentro de tu entorno de aplicaciones de confianza y está secuestrando tus claves API reales y legítimas. Para el resto del mundo, tu servidor envió ese correo electrónico de forma legítima, por lo que los protocolos criptográficos perimetrales le dan luz verde. Se trata de un problema de exfiltración de datos, no de suplantación de servidor.
Si DMARC no puede evitar la filtración de datos, ¿por qué debería activarlo?
Piensa en los informes agregados de DMARC de RUA como el detector de humo de tu red. Si un servidor MCP empieza a enviar en secreto miles de correos electrónicos operativos en copia oculta (BCC) a una bandeja de entrada de terceros, el volumen de tu correo electrónico transaccional se disparará de forma espectacular. Si supervisas activamente tus fuentes de datos de DMARC, ese cambio repentino en el volumen saltará a la vista, lo que proporcionará a tu equipo de operaciones de seguridad una alerta temprana para auditar las dependencias de código activas.
Nuestro equipo necesita herramientas de inteligencia artificial para gestionar los correos electrónicos de asistencia. ¿Cómo podemos hacerlo de forma segura sin desactivar por completo las integraciones?
No es necesario bloquear la automatización mediante IA, solo hay que establecer unos límites. En primer lugar, trata los servidores MCP como componentes de infraestructura de alto riesgo: nunca instales scripts de la comunidad sin revisar previamente el código. En segundo lugar, limita el alcance de tus claves API con permisos muy específicos y detallados; si un agente solo necesita enviar respuestas de asistencia, restringe su token API de tal forma que sea físicamente imposible realizar lecturas masivas de datos, creaciones de cuentas o reglas de CCO. Por último, opta por integraciones de proveedores verificados, como el servidor MCP de PowerDMARC, en lugar de clones de la comunidad no verificados.
¿Cómo puedo comprobar si mi equipo de desarrollo ha instalado por error un servidor MCP malicioso?
El primer paso consiste en realizar un análisis de composición de software (SCA) o utilizar herramientas de código abierto como mcp-scan para mapear tu entorno activo. Examine detenidamente los registros públicos de paquetes, como npm y PyPI, en busca de bibliotecas comunitarias de terceros no verificadas que gestionen sus canales de comunicación. Si una biblioteca no ha sido publicada y firmada directamente por un proveedor corporativo verificado, como el repositorio oficial de Postmark o el servidor MCP seguro de PowerDMARC, considérela un riesgo hasta que el código sea auditado manualmente.
Especialista en contenidos en PowerDMARC
Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.
Últimos mensajes de Milena Baghdasaryan (ver todos)
- Cómo elegir un proveedor de servicios de correo electrónico: un marco de evaluación que prioriza la seguridad - 1 de julio de 2026
- Seguridad del correo electrónico en Latinoamérica: Situación actual de DMARC y la autenticación del correo electrónico en Latinoamérica en 2026 - 30 de junio de 2026
- Abuso de infraestructuras legítimas: la técnica de phishing que elude la autenticación del correo electrónico - 30 de junio de 2026
