La puerta trasera de Postmark está descargando correos electrónicos

• Recientemente se detectó un comportamiento malicioso en el módulo postmark-mcp
• A partir de la versión 1.0.16 se agregó código que copia los correos a un servidor externo del desarrollador
• Quedó expuesta una vulnerabilidad estructural que permite la filtración de correos sensibles de cientos de organizaciones
• La ausencia de un modelo de confianza para los servidores MCP está aumentando el riesgo de ataques a la cadena de suministro
• Todos los usuarios de MCP deben revisar y eliminar de inmediato este componente

---

Qué son los servidores MCP y resumen del incidente de postmark-mcp

• Los servidores MCP son herramientas que permiten a los asistentes de IA automatizar tareas repetitivas como enviar correos o ejecutar consultas a bases de datos
• Estas herramientas operan con privilegios muy altos, y los desarrolladores suelen instalar código creado por terceros casi solo con base en la confianza, sin un sistema real de verificación
• El paquete popular postmark-mcp tomó el código fuente del repositorio oficial de Postmark en GitHub, añadió una línea maliciosa de BCC y luego lo publicó en npm con el mismo nombre
• Desde la versión 1.0.16 se agregó una sola línea a un código que parecía normal, activando una función que copiaba todos los correos electrónicos al servidor personal del desarrollador (giftshop.club)
• Es decir, se trata de un incidente en el que quedaron expuestos todos los datos de correo, incluyendo restablecimientos de contraseña, facturas, notas internas y documentos confidenciales

Detección del comportamiento anómalo y estructura del ataque

• El Risk Engine de Koi detectó indicios anómalos en la versión 1.0.16
• La identidad del desarrollador parecía legítima en GitHub y otros sitios, y las primeras 15 versiones funcionaron sin problemas, construyendo confianza
• En la versión 1.0.16 se añadió una sola línea de código que filtraba información crítica hacia el exterior
• El atacante usó una técnica de suplantación del desarrollador original al mismo tiempo que copiaba el código (Classic impersonation)
• Una herramienta que antes se usaba con normalidad terminó convirtiéndose en parte de una infraestructura basada en la confianza, y luego comenzó a ejecutar acciones maliciosas

Impacto y mecanismo de la filtración de correos

• Se calcula que tiene alrededor de 1,500 descargas por semana y, asumiendo que cerca del 20% se usa activamente, cientos de organizaciones quedaron expuestas
• Se estima que entre 3,000 y 15,000 correos al día fueron enviados a giftshop.club
• Los usuarios no verifican manualmente el comportamiento de la herramienta y dejan la mayor parte de la ejecución automática en manos del asistente de IA
• No existe ningún modelo de seguridad, sandbox ni proceso de verificación
• Aunque el desarrollador eliminó el paquete de npm, en los entornos donde ya estaba instalado eso no surte efecto, por lo que la filtración de datos continúa

Análisis de las etapas del ataque

• Etapa 1: distribución de una herramienta legítima

  • De la 1.0.0 a la 1.0.15 funcionó sin problemas y acumuló confianza

• Etapa 2: inserción de código malicioso

  • En la 1.0.16 se agregó una sola línea de BCC para copiar correos hacia el exterior

• Etapa 3: recolección de información

  • Contraseñas, claves API y datos financieros o de clientes fueron filtrados a giftshop.club

• No se logró contactar al desarrollador, y aunque el paquete fue eliminado de npm, el daño sigue en los entornos donde ya estaba instalado

Fallas estructurales del ecosistema MCP

• A diferencia de un paquete normal de npm, un servidor MCP es una herramienta de alto riesgo que un asistente de IA puede invocar automática y repetidamente cientos o miles de veces
• Ni la IA ni las soluciones de seguridad existentes logran detectar si el código es malicioso, por lo que todo depende de la confianza
• Todo el ecosistema MCP tiene una estructura riesgosa en la que se delega todo el acceso a activos críticos a desarrolladores anónimos
• Se necesitan controles de seguridad como la detección de cambios de comportamiento y una gateway de cadena de suministro para identificar este tipo de ataques
• Koi está impulsando el uso de su Risk Engine y una gateway para bloquear y validar el ingreso de paquetes maliciosos similares

Medidas de respuesta e IOC

• Paquete malicioso: postmark-mcp (npm)
• Versión maliciosa: 1.0.16 o posterior
• Correo de exfiltración: phan@giftshop[.]club
• Dominio: giftshop[.]club

Método de detección

• Revisar en los logs de correo si hay rastros de envíos con giftshop.club en BCC
• Verificar en la configuración del servidor MCP si hay parámetros inesperados de reenvío de correo
• Auditar en detalle si se instaló postmark-mcp 1.0.16 o una versión posterior

Respuesta y recuperación

• Eliminar postmark-mcp de inmediato
• Rotar todas las credenciales compartidas por correo durante el periodo de compromiso
• Investigar de forma exhaustiva los logs de correo con información sensible potencialmente robada
• Si se confirma el incidente, reportarlo de inmediato a las autoridades correspondientes

Conclusión y recomendaciones

• Para todos los servidores MCP se deben aplicar obligatoriamente procesos de verificación de identidad del desarrollador, validación de código y revisión de seguridad
• Por la naturaleza de MCP como infraestructura automatizada de apoyo para IA, es indispensable aplicar al menos un modelo mínimo de desconfianza y monitoreo continuo
• Los usuarios de postmark-mcp 1.0.16 o superior deben eliminarlo de inmediato y aplicar medidas de seguridad urgentes
• Es importante tener presente que usar herramientas solo con base en la confianza implica exponerse a ataques de cadena de suministro
• Adoptar la paranoia (desconfianza o sospecha) como política por defecto es una estrategia razonable para usar MCP

[GN⁺]

Opiniones de Hacker News

• Me pregunto en qué se diferencia esto del backdoor de la extensión de Thunderbird y ese incidente. Hace tiempo mantenía una extensión de Thunderbird y, cuando perdí el interés, una persona hizo algunas contribuciones reales y luego de repente empezó a insistir con mucha fuerza en quedarse con el proyecto. Al final me negué porque me pareció absurdo entregarle decenas de miles de llaves de buzones a alguien que no conocía. De por sí ya era gracioso que la gente confiara tanto en mí, pero al menos yo sí era buena persona
  • Pienso exactamente lo mismo. Esto no es por MCP, es un problema que aplica por igual a todo el software. Al final no queda más que confiar en los desarrolladores y proveedores. No puedo impedir que Microsoft copie mi correo de Outlook, ni que Google copie Gmail. Aunque sea open source y haya “muchos ojos” revisando el código, eso podrá aplicar a proyectos populares, pero el riesgo sigue ahí. Al final, la mayoría simplemente confía en los desarrolladores. Este problema es un vicio histórico tan viejo como el software mismo
  • En la situación que mencionas, no dejo de acordarme de un comentario de Zuckerberg sobre privacidad. Hay que pensar por qué le estamos entregando nuestros datos y nuestra privacidad a cualquier persona sin más
  • Muchas veces he subido al auto a desconocidos borrachos para llevarlos a su casa. Siempre les digo que aceptar un aventón de un extraño es realmente peligroso. Siendo sinceros, tuvieron suerte de encontrarse por casualidad con alguien decente como yo y con tiempo libre. Suelo ir tarde a un bar pequeño del barrio, así que esto me pasa seguido
• No estoy de acuerdo con la idea de que una sola descarga en NPM equivale a una organización única. Esa cifra está muy inflada. Una descarga en npm solo significa que alguien (ejecutando npm i) o algo (un entorno automatizado) instaló el paquete. En la práctica, si el CI está medio mal armado, corre npm i por ejecución o incluso por etapa. Así que 1,500 descargas podrían venir en realidad de solo 2 empresas. En una, un desarrollador lo usa para un PoC, y en la otra, la configuración de CI es un desastre. Si miras el repo oficial, apenas tiene 1 watch, 0 forks y 2 stars https://github.com/ActiveCampaign/postmark-mcp. MCP y los problemas de supply chain sí son graves, pero en este caso el impacto real es casi cero
  • Siguiendo esa misma lógica, las descargas de paquetes populares de Python pronto llegarán al punto en que cada ser humano del planeta —niños, ancianos y hasta gente que ni sabe qué es una computadora— habrá descargado uno cada quien. https://pypistats.org/top
• El artículo en sí está bien, pero no entiendo por qué tendría que leer una versión traducida por IA y resumida con ChatGPT. Preferiría que simplemente mostraran el prompt original. Así como está, se siente innecesariamente lento y hasta un poco irrespetuoso con el usuario
  • Qué bueno saber que no fui el único que lo sintió. Odio muchísimo ese estilo con intervención de IA, pero entre mis amigos hay quienes ni lo notan o no les importa
• Esto se ve mucho últimamente, pero siento que no estamos hablando lo suficiente de que le estamos dando permisos divinos a estas herramientas. Son herramientas hechas por gente cuya cara ni conocemos, y aun así simplemente confiamos. Lo mismo con los asistentes de IA. Todos les dan una confianza del 100%. Hay artículos que señalan esto, pero se sienten como “¿sabías que si apuntas el arma a tu pie y aprietas el gatillo te vas a disparar en el pie?”. Es tan obvio que parece que están haciendo contenido de algo que en realidad no tiene mucha sustancia. Me pregunto si de verdad hay tanta gente que no lo entiende, o si lo fuerzan solo para escribir algo
  • Hace poco también salió un artículo sobre un asistente de código con IA que borró la base de datos de producción de una empresa https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Hay niveles aquí: 1) ese fundador confió totalmente en la herramienta de IA y terminó perjudicándose él solo. O sea, realmente era ignorante. 2) Además, había dejado abierta la base de datos de producción para acceso directo desde el entorno de desarrollo. Era un entorno donde el accidente iba a ocurrir tarde o temprano de cualquier forma
  • Lo que para un usuario de HN es obvio, para la mayor parte del mundo no lo es en absoluto. Este tipo de artículos son contenido necesario para esa gente. De hecho, el diseño de los servidores MCP y de los agentes de IA es intrínsecamente inseguro porque la seguridad ni siquiera se discutió desde el principio. No sé si eso vaya a cambiar más adelante, pero mientras no pase, lo mejor es seguir advirtiéndolo una y otra vez
  • “¿De verdad la gente es así de indiferente?” Incluso una SQL injection básica sigue causando daños enormes cada año y todavía está entre lo más alto de OWASP. Al final, una SQL injection también le da permisos divinos a la base de datos y ocurre porque no se entiende cómo funciona. Desde la perspectiva del usuario, los permisos de acción de un agente de IA también pueden no ser visibles
  • Debería discutirse mucho más ampliamente que este tipo de acceso indiscriminado se está dando a gran escala con MCP. Incluso personas normalmente cuidadosas muchas veces no perciben bien el riesgo
  • Antes se llamaba “revolución de la automatización” a que los clientes de correo ejecutaran correos con scripts incrustados enviados por cualquier persona en internet. También antes se pensaba que era más sano que los niños usaran internet en vez de ver TV, pero todos sabemos cómo terminó eso, ¿no?
• Hay una parte sobre “la situación en la que se volvió normal instalar herramientas hechas por cualquier persona random”, pero la verdad es que desde la era de Windows XP venimos instalando sin preocupación cosas como software para ripear CDs o Bonzi Buddy. La conveniencia siempre ha estado por encima de la seguridad. Al final, la lección más importante es preguntarse por qué ‘sandbox, sandbox, sandbox’ todavía no se volvió realidad. En este caso, parece que la IA hizo un reseteo de fábrica completo de todos los principios de seguridad que ya existían
  • A la pregunta de “la gente elige la conveniencia antes que la seguridad; ¿por qué el sandbox todavía no es una realidad?”, la respuesta es que implementar sandboxing no es fácil. Y aquí “fácil” significa que venga por defecto desde el sistema operativo
• Un usuario incluso podría enviar spam con prompt injection a una IA a través de GMail sin que ningún humano llegue a abrir el correo https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Este post del blog es muy difícil de leer. Se siente tocado por IA. Tiene demasiadas frases innecesarias y demasiado adorno. Lástima, porque el tema en sí es interesante
• En problemas de seguridad de supply chain, casi siempre salen mencionados los paquetes de npm. Supongo que es porque npm es lo más usado y para los atacantes también hay más incentivos, pero aun así es inevitable que deje un sabor amargo
  • OpenAI también distribuye Codex CLI por npm. Está hecho en Rust, y aun así usan un paquete de npm. Personalmente, eso me parece absurdo. Pero supongo que las alternativas son todavía más incómodas
  • Por eso yo no ejecuto servidores MCP por stdio. Todo MCP está aislado en contenedores Docker, sobre hosts VM, en una VLAN no confiable. Y solo me conecto por SSE. Claro, sigo siendo vulnerable a prompt injection, pero no lo conecto a mi perfil principal del navegador, ni al correo, ni a cuentas de la nube. Lo mantengo completamente separado de la información sensible
  • No es deseable que ese comentario de arriba tenga tantos votos positivos que se malinterprete como si fuera la principal conclusión de este artículo. Si se entiende así, se pierde de vista lo esencial
• También puede que el desarrollador en realidad no lo haya hecho a propósito. A mí también se me ha ido alguna vez código de depuración en un release. Si era un bcc simple, podría haber sido realmente código de debug
  • Yo también venía a decir esto. Sinceramente, es difícil creer que alguien dejaría su propio correo tan expuesto de esa forma. Y en 2025, ¿de verdad no da pena usar un Gmail personal para pruebas? Además, esto no es un problema exclusivo de MCP; puede pasar en cualquier paquete
  • La reacción de borrar el paquete también es, sinceramente, la respuesta típica de un desarrollador novato que se topa por primera vez con un problema de seguridad. Si no hubo mala intención y solo fue un error de depuración, la clave es la comunicación: eliminar la versión maliciosa, publicar un parche y comunicarlo en canales públicos como el blog, aquí en HN, redes sociales, etc. Así se recupera la confianza. También ayudaría una línea de tiempo exacta del incidente (y no un resumen escrito por IA como el del OP) para reconstruir esa confianza
• El problema de los servidores MCP es riesgoso, pero creo que este tipo de ataque puede darse en cualquier situación donde se usen dependencias externas, como un paquete de smtp
  • Sí, pero con un paquete smtp normalmente terminas usando librerías antiguas y bien probadas, con una historia larga de confianza. MCP es un problema porque todo es nuevo y todavía no existe ese historial de confianza. Es como una especie de tierra de nadie del software, donde hay que andar con el revólver cargado (6-shooter) en la cintura