Mastra expone la fragilidad de la cadena de suministro npm: 144 paquetes comprometidos y un postinstall que roba secretos

Un amplio ataque a la cadena de suministro ha comprometido hasta 144 paquetes npm bajo el espacio de nombres @mastra, explotando una instalación masiva de versiones maliciosas que añadían una dependencia troceada llamada "easy-day-js". Según análisis de varios equipos de respuesta, el vector no fue código evidentemente malicioso dentro de cada paquete, sino una cadena de instalación: la librería falsa se ejecuta en un hook postinstall, descarga un cargador que desactiva la validación TLS, recupera un segundo estadio de un servidor controlado por los atacantes y despliega un stealer multiplataforma capaz de exfiltrar historial de navegador, datos de extensiones de monederos de criptomonedas y persistir en Windows, macOS y Linux.

El atacante aprovechó el compromiso de una cuenta legítima del ecosistema para publicar—en minutos—más de 140 versiones maliciosas dentro del scope de Mastra, aprovechando que la política del proyecto permitía publicar con un token personal sin exigir las atestaciones de procedencia (SLSA) generadas por el CI. Esto demuestra la diferencia práctica entre generar pruebas de integridad en CI y exigirlas como requisito de publicación: si la verificación de firmas o de atestaciones hubiese sido obligatoria, las versiones habrían sido rechazadas automáticamente.

Las implicaciones son críticas: paquetes populares como @mastra/core (con cientos de miles de descargas semanales) amplifican el impacto, y dado que el payload se ejecuta durante la instalación, una simple ejecución de npm install en un desarrollo local o en runners de CI puede comprometer secretos antes incluso de que el desarrollador importe la librería en su código. Además del robo de claves, la capacidad del malware para borrar huellas y operar en background dificulta la detección forense.

Si su organización usa @mastra/* o ejecutó instalaciones recientemente, trate cada host, runner y entorno de build como potencialmente comprometido. Entre las acciones inmediatas a considerar están: revertir a versiones verificadas o a commits de confianza; revocar y rotar todos los tokens y credenciales que pudieran haber sido usados por runners o desarrolladores; revocar tokens personales y reemitir con políticas más restrictivas; y reconstruir imágenes y runners desde orígenes inmutables. También es imprescindible auditar sistemas en busca de signos de ejecución del postinstall: procesos hijos lanzados desde carpetas de node_modules, entradas de persistencia (servicios systemd, launchd, tareas programadas, claves Run en Windows), y conexiones hacia las direcciones IP observadas por los investigadores (para la campaña se han señalado servidores C2 conocidos que conviene comprobar).

En términos de mitigación a medio y largo plazo, las lecciones son claras: exigir atestaciones de procedencia y firma de paquetes, limitar y controlar tokens NPM con permisos mínimos, usar políticas que verifiquen firmas durante la instalación y promover installations reproducibles y auditadas. Integrar SBOMs en los pipelines, restringir instalaciones en runners no aislados y centralizar las dependencias aprobadas en un proxy privado reduce la superficie de ataque. Implementar controles de egress y monitorización de tráfico desde runners y desarrolladores ayuda a detectar descargas sospechosas en el momento en que ocurren.

Para quienes gestionan proyectos de código abierto, la recomendación es revisar el proceso de gestión de colaboradores y scopes: revocar accesos a contribuyentes que ya no participan, forzar la publicación desde flujos de CI con atestaciones SLSA y auditar tokens personales regularmente. Las buenas prácticas de supply chain —como exigir SLSA, firmar artefactos y adoptar políticas de verificación en la instalación— ya no son opcionales si se quiere mantener confianza en dependencias externas.

Si necesita orientación técnica sobre cómo exigir atestaciones y firmas en su flujo de trabajo, la especificación SLSA y las recomendaciones de seguridad en la cadena de suministro son recursos útiles: vea la documentación de SLSA en https://slsa.dev/ y la guía de buenas prácticas de la comunidad sobre seguridad de la cadena de suministro en https://owasp.org/www-project-supply-chain-security/. Para orientación específica sobre las políticas y prácticas de seguridad de npm consulte https://docs.npmjs.com/about-security.

En resumen, el incidente que afecta a @mastra/* subraya la fragilidad de la confianza implícita en el ecosistema de paquetes: protegerse requiere combinar controles técnicos (firmas, atestaciones, aislamiento de runners) con gobernanza (gestión de accesos y tokens). Actúe con rapidez para contener exposición, audite exhaustivamente entornos afectados y evolucione sus pipelines para que un único token comprometido no pueda volver a causar una liberación masiva de código malicioso.