Sapphire Sleet compromete 145 paquetes de Mastra AI en npm: así funcionó el ataque y qué cambia con Microsoft

En aproximadamente 88 minutos, los atacantes comprometieron 145 paquetes del espacio de nombres @mastra/* en npm. Esos paquetes acumulaban más de 1,1 millones de descargas semanales . El incidente puso de manifiesto un riesgo central del desarrollo moderno: una sola cuenta con permisos de publicación puede convertirse en la puerta de entrada a cientos de proyectos.

Cómo funcionó el ataque

La operación siguió una cadena de pasos relativamente sencilla, pero con un impacto potencial muy amplio.

1. Ingeniería social y secuestro de una cuenta

Los atacantes engañaron a un mantenedor legítimo de Mastra y obtuvieron sus credenciales de npm . La cuenta comprometida, identificada como ehindero, tenía permisos para publicar paquetes en todo el espacio @mastra .

2. Publicación masiva y automatizada

Con ese acceso, los atacantes volvieron a publicar los paquetes del espacio @mastra/* dentro de una ventana de 88 minutos. Algunos informes sitúan el grueso de la publicación en apenas 19 minutos . La velocidad apunta al uso de un script automatizado, no a una carga manual paquete por paquete.

3. Inyección de una dependencia falsa

Cada versión comprometida incorporó una dependencia maliciosa llamada easy-day-js, cuyo nombre imita al de la popular biblioteca legítima dayjs . Los investigadores bautizaron la campaña con el mismo nombre: «easy-day-js» .

Este tipo de engaño, conocido como typosquatting, se basa en aprovechar errores de escritura o nombres casi idénticos para hacer pasar una biblioteca maliciosa por una dependencia conocida.

4. Ejecución automática durante la instalación

El código malicioso se ejecutaba mediante el script postinstall de npm. Por tanto, bastaba con instalar una versión afectada usando npm install para activar la carga; no era necesario ejecutar después la aplicación ni iniciar un agente de IA .

5. Búsqueda de credenciales y activos digitales

Una vez ejecutado, el payload buscaba claves de monederos de criptomonedas, credenciales de servicios en la nube y secretos utilizados por sistemas de integración y entrega continuas (CI/CD) en los equipos de los desarrolladores y en sus entornos de compilación . También desactivaba la verificación TLS y descargaba un segundo componente de robo desde una infraestructura controlada por los atacantes .

Microsoft atribuye la operación a Sapphire Sleet

El 19 de junio de 2026, Microsoft afirmó con alta confianza que la actividad correspondía a Sapphire Sleet, un actor estatal norcoreano que se centra principalmente en los sectores financiero y de las criptomonedas . La compañía fundamentó la atribución en la infraestructura observada y en unas tácticas, técnicas y procedimientos (TTP) coherentes con operaciones anteriores del grupo.

Amazon Threat Intelligence también ha relacionado a Sapphire Sleet con campañas previas contra paquetes de npm como axios, debug, chalk y typo-crypto .

La respuesta de Microsoft: menos tiempo para las claves, más identidad verificable

El incidente de Mastra aceleró cambios que Microsoft ya estaba preparando para NuGet, el repositorio de paquetes utilizado por desarrolladores del ecosistema .NET.

Las claves nuevas de NuGet tendrán una vigencia máxima de 30 días

A partir del 17 de agosto de 2026, las nuevas claves de API de NuGet.org ya no podrán tener una duración de 365 días: su vigencia máxima será de 30 días . Además, todas las claves creadas antes de esa fecha caducarán forzosamente el 1 de noviembre de 2026 .

La lógica de Microsoft es reducir el margen de maniobra de un atacante que robe una credencial. Una clave de larga duración puede permanecer olvidada en un repositorio, un equipo o un sistema de CI/CD y permitir la publicación de paquetes manipulados durante meses .

Trusted Publishing sustituye las credenciales duraderas

Microsoft recomienda que los mantenedores migren a Trusted Publishing, un flujo de publicación presentado en septiembre de 2025 que utiliza autenticación basada en OpenID Connect (OIDC) en lugar de claves de API de larga duración .

Sus principales ventajas son :

• No hay secretos permanentes almacenados en el repositorio ni en el sistema de CI/CD.
• Las credenciales se emiten para cada publicación y caducan automáticamente, normalmente en alrededor de una hora.
• NuGet puede verificar la identidad del repositorio, el flujo de trabajo y, si se configura, el entorno autorizado.
• No es necesario rotar manualmente las claves.
• Si una credencial queda expuesta, el alcance y el tiempo útil del incidente se reducen de forma considerable.

Cuando se ejecuta un flujo de CI/CD compatible con Trusted Publishing, el proveedor —por ejemplo, GitHub Actions— solicita un token OIDC firmado criptográficamente. NuGet.org comprueba ese token frente a la política del editor registrada y entrega una clave temporal de un solo uso, válida únicamente para esa sesión de publicación .

Cambios adicionales en npm

La respuesta forma parte de un giro más amplio en los registros de paquetes y en la autenticación de los mantenedores:

• Tokens clásicos revocados: npm revocó de forma permanente todos los tokens clásicos de larga duración en diciembre de 2025. npm login proporciona ahora tokens de sesión con una duración de dos horas .
• Tokens granulares con caducidad: los nuevos tokens granulares con permisos de escritura tienen una duración predeterminada de siete días y un máximo de 90 días .
• Publicación escalonada: disponible de forma general desde mayo de 2026, esta función exige que un mantenedor supere un desafío de autenticación de dos factores (2FA) y apruebe explícitamente una versión antes de que pueda instalarse públicamente .

En conjunto, estas medidas intentan cerrar la vía que aprovechó Sapphire Sleet: una única credencial de publicación, de larga duración y con acceso amplio a todo un espacio de paquetes.

Qué deberían hacer los desarrolladores y mantenedores

• Revisar las claves de NuGet cuanto antes. Las creadas antes del 17 de agosto de 2026 caducarán el 1 de noviembre. Conviene generar nuevas claves con una duración limitada o migrar a Trusted Publishing .
• Adoptar Trusted Publishing. La autenticación OIDC evita guardar secretos duraderos en las canalizaciones de CI/CD. El método cuenta con soporte en NuGet.org, npm y PyPI .
• Auditar los flujos de publicación de npm. Comprueba que las canalizaciones utilicen tokens de sesión, tokens granulares con caducidad o Trusted Publishing, según corresponda .
• Fijar versiones conocidas y confiables. En dependencias críticas, evita las actualizaciones automáticas hasta validar los cambios .
• Desactivar los scripts automáticos durante la instalación cuando sea posible. npm install --ignore-scripts, o la configuración global ignore-scripts = true, puede impedir la ejecución de scripts postinstall maliciosos .

El caso Mastra no necesitó comprometer directamente cada proyecto que consumía sus paquetes. Bastó con apropiarse de una cuenta confiable y aprovechar el funcionamiento automático del ecosistema de dependencias. Esa es precisamente la razón por la que las plataformas están sustituyendo las claves persistentes por credenciales breves y una identidad de publicación verificable.