CVE
Sin asignar
CWE
CWE-506, CWE-494, CWE-829, CWE-73, CWE-918, CWE-200
Sistemas afectados
- Developer workstations and CI runners that installed compromised `@mastra/*`, `mastra`, or `create-mastra` packages during the 17 June 2026 exposure window
- Node.js applications that pass attacker-influenced `raw` message data into `nodemailer` while relying on `disableFileAccess` or `disableUrlAccess` as a sandbox boundary
Bienvenido al boletín semanal de Corgea. El boletín recoge los hallazgos y las investigaciones de seguridad más importantes de la semana.
Esta edición cubre las investigaciones publicadas desde el miércoles 17 de junio hasta el martes 23 de junio de 2026, excluyendo los elementos ya tratados en el boletín del 16 de junio.
Artículo principal
La toma de control del scope npm de Mastra usó easy-day-js para troyanizar 141-143 paquetes
La historia más importante de esta ventana es el compromiso de @mastra, porque afectó a un framework de agentes de IA que habitualmente convive en las mismas estaciones de trabajo de desarrolladores y en los mismos ejecutores de CI ya expuestos a la ola de Hades centrada en MCP en PyPI, a los paquetes de continuación de Phantom Gyp Miasma en forma de Miasma y al anterior incidente de dbmux Phantom Gyp. Aikido merece el crédito de la primera divulgación pública por señalar la explosión de reediciones de más de 140 paquetes el 17 de junio, StepSecurity merece crédito por revertir rápidamente la cadena de postinstalación de easy-day-js, y Microsoft aportó posteriormente el detalle de procedencia pública más sólido al vincular las versiones envenenadas con la cuenta de mantenedor secuestrada ehindero y la trampa escalonada de versiones semánticas 1.11.21 / 1.11.22.
Lo importante que hay que recordar es que el paquete visible de Mastra fue solo el vehículo. El verdadero límite de ejecución maliciosa se encontraba una dependencia más abajo, en easy-day-js@1.11.22, lo que sitúa este incidente en la misma categoría de límites de confianza que Atomic Arch, la brecha del publicador de confianza de TanStack y el ataque a la extensión Open VSX de GlassWASM: el código de mayor riesgo suele ser el código que los desarrolladores nunca tenían intención de revisar directamente.
Más noticias
La opción raw de Nodemailer elude disableFileAccess y disableUrlAccess
La otra historia importante de esta semana es el nuevo aviso de Nodemailer, porque convierte un límite de sandbox documentado en una falsa sensación de seguridad. El aviso de GitHub acredita a Pig-Tail como reportante, y los mantenedores de Nodemailer merecen crédito por publicar rápidamente la corrección 9.0.1 una vez que se demostró que la ruta del mensaje raw descartaba tanto disableFileAccess como disableUrlAccess antes de que MimeNode resolviera el contenido de { path } y { href }. Esto ofrece a los atacantes una divulgación directa de archivos locales y una primitiva de SSRF con respuesta completa cuando una aplicación permite que una entrada no confiable determine la forma del mensaje RFC822 saliente.
Lo que convierte esto en algo más que “otro fallo más de un paquete de Node” es que la ruta vulnerable se encuentra dentro de código de infraestructura que muchos equipos consideran ya reforzado. La lección coincide con CVE-2026-44488 en el adaptador fetch de Axios, CVE-2026-42305 y CVE-2026-47712 en Dulwich y CVE-2026-41242 en protobufjs: en cuanto una biblioteca promete un control de seguridad, la ruta alternativa poco conocida que olvida propagar ese control se convierte en el verdadero límite de seguridad.
Otras noticias:
- No se publicaron artículos nuevos adicionales en
/researchde Corgea en esta ventana de martes a martes, tras excluir los elementos ya tratados en el boletín del 16 de junio. - Para contexto relacionado, revisa GlassWASM, CVE-2026-45783 en libp2p, las correcciones de DoS de WebFlux y recursos estáticos versionados de Spring y el anterior compromiso de Miasma en Red Hat Cloud Services, que en conjunto ayudan a enmarcar desde distintos ángulos el mismo patrón de “herramientas de alta confianza más un límite de confianza fallido”.
De la investigación a la remediación
Comprueba si este patrón existe en tu código
Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.