Hackers de Corea del Norte envenenaron 140+ paquetes npm de un framework de IA — el ataque Mastra y qué enseña

Todo dev lo hace decenas de veces por semana sin pensar: npm install. Confías en que ese puñado de paquetes — y los paquetes de ellos, y los paquetes de sus paquetes — son lo que dicen ser. El ataque de esta semana es un recordatorio duro de que esa confianza tiene un costo.

¿Qué pasó?

Microsoft atribuyó, con "alta confianza", a Corea del Norte — el grupo estatal Sapphire Sleet (también conocido como BlueNoroff) — un ataque de cadena de suministro que comprometió más de 140 paquetes npm del scope @mastra, ligado a un framework de IA del ecosistema Node/JavaScript. La divulgación salió el 19–20 de junio de 2026.

La vía de entrada fue clásica: los atacantes secuestraron la cuenta de un mantenedor (con permiso de publicar) e inyectaron una dependencia maliciosa llamada easy-day-js — un typosquat de la biblioteca legítima dayjs. Nombre parecido, intención opuesta.

Cómo funcionaba el ataque

El paquete-señuelo abusaba de un postinstall — un script que npm ejecuta automáticamente apenas se instala el paquete. Según el análisis, la cadena era:

npm install            // instalas el paquete (directa o transitivamente)
   └─ postinstall      // npm dispara el script solo
        └─ dropper ofuscado
             ├─ desactiva la verificación de certificado TLS
             ├─ contacta al servidor de comando (C2)
             └─ descarga la 2ª fase: un info-stealer multiplataforma

La segunda fase era un ladrón de datos para Windows, Linux y macOS. Barría 166 extensiones de wallets de criptomonedas (MetaMask, Phantom, Coinbase y otras), robaba credenciales, claves de API, tokens de autenticación y wallets, e instalaba persistencia (claves Run en el Registro de Windows, LaunchAgents en macOS, servicios systemd en Linux) para sobrevivir a un reinicio.

Por qué te afecta aunque nunca hayas oído del Mastra

Porque el peligro no es ese paquete — es el modelo. Instalas A, que depende de B, que depende de C. Si C es reemplazado por una versión maliciosa, el código corre en tu máquina, en el momento del npm install — antes de que ejecutes una sola línea de tu proyecto. Y no es "problema de quien usa Node": cualquier proyecto con front-end — incluidos los míos, en PHP — trae decenas de paquetes npm para armar CSS y JS.

Cómo blindar tus dependencias

• Versiona el lockfile e instala con npm ci — instala exactamente lo que está en package-lock.json, sin resolver versiones nuevas por su cuenta.
• Desactiva los scripts automáticos: npm install --ignore-scripts (o ignore-scripts=true en .npmrc). Ejecuta postinstall solo de paquetes en los que confías.
• No instales lo que acaba de salir. Espera unos días antes de adoptar una versión recién publicada — la mayoría de los paquetes envenenados se detecta y elimina en las primeras horas.
• Lee el nombre con atención. easy-day-js no es dayjs. El typosquat vive de la prisa y el piloto automático.
• Corre npm audit y considera un servicio de análisis de paquetes (ej.: Socket) en tu CI.
• Separa los secretos de la máquina de dev. No dejes claves de producción y wallets en la misma máquina donde corres npm install de proyectos cualesquiera. Es la diferencia entre "instalé un paquete malo" y "lo perdí todo".

Mi lectura

La fuerza del ecosistema npm — reutilizar el trabajo del mundo entero con un comando — es también su mayor superficie de ataque. Yo trato la dependencia de terceros como código no confiable por defecto: lockfile trabado, scripts apagados, secretos aislados y un ojo en lo que entra al proyecto. No es paranoia — es el costo de operar en un ecosistema abierto.

Quiero revisar la seguridad de mi proyecto

¿Quieres una revisión de las dependencias y el pipeline de tu proyecto antes de que un eslabón débil sea un dolor de cabeza? Es justo el tipo de cosa que hago — hablemos.

Fuentes

BleepingComputer · Microsoft Security (MSTIC)