Paquete npm Axios comprometido: ataque a la cadena de suministro distribuye un RAT multiplataforma

El 31 de marzo de 2026, se publicaron brevemente en npm dos versiones maliciosas de axios, el popularísimo cliente HTTP para JavaScript con más de 100 millones de descargas semanales, a través de la cuenta comprometida de un mantenedor. Los paquetes contenían una dependencia oculta que desplegaba un troyano de acceso remoto multiplataforma (RAT) en cualquier máquina que ejecutara npm install (o el comando equivalente de otros administradores de paquetes, como Bun) durante un período de dos horas.

Las versiones maliciosas (1.14.1 y 0.30.4) se eliminaron de npm a las 03:29 UTC. Sin embargo, durante el tiempo que estuvieron disponibles, cualquier persona cuyo pipeline de CI/CD, entorno de desarrollo o sistema de compilación descargara una instalación nueva pudo haber sufrido un compromiso sin haber tocado una sola línea de código de Axios.

Resumen

Cómo se llevó a cabo el ataque

No se trata de un paquete con un nombre engañoso ni de una dependencia maliciosa que se coló en una compilación. El atacante tenía (o consiguió) acceso directo para publicar el paquete oficial axios en npm, probablemente al comprometer la cuenta de un mantenedor. Según un colaborador en el hilo oficial de incidencias de GitHub, se sospecha que la cuenta comprometida pertenecía al mantenedor @jasonsaayman, cuyos permisos en el repositorio eran superiores a los de otros colaboradores, lo que dificultó una respuesta rápida.

El atacante no modificó directamente ningún archivo fuente de Axios. En su lugar, agregó una dependencia maliciosa preparada de antemano, plain-crypto-js@4.2.1, al package.json de las nuevas versiones de axios. El paquete plain-crypto-js se creó específicamente para este ataque: 18 horas antes se había publicado una versión anterior «limpia» (4.2.0), probablemente para que tuviera un breve historial en el registro. La versión 4.2.1 contenía la carga maliciosa.

Cuando un desarrollador o sistema de CI ejecuta npm install axios@1.14.1, npm resuelve el árbol de dependencias, descarga plain-crypto-js@4.2.1 y ejecuta automáticamente su hook postinstall: node setup.js. La ejecución de ese único script es donde comienza el compromiso.

El descargador: doble ofuscación y autoeliminación

El descargador setup.js de postinstall usa dos capas de ofuscación para evitar el análisis estático:

1. Codificación Base64 invertida con sustitución del carácter de relleno

2. Cifrado XOR con la clave OrDeR_7077 y un valor constante de 333

Una vez desofuscado, el script detecta el sistema operativo anfitrión mediante os.platform() y se conecta al servidor C2 en sfrclak[.]com:8000 (IP: 142.11.206.73) para descargar una carga de segunda etapa adecuada para la plataforma.

Después de ejecutarse, el malware borra sus rastros: elimina setup.js, quita el package.json que contenía el hook postinstall y lo reemplaza por un package.md limpio, al que cambia el nombre a package.json. Si inspeccionas node_modules/plain-crypto-js después, no encontrarás señales evidentes de que alguna vez hubiera habido un script postinstall.

Cargas específicas para cada plataforma

Las cargas de segunda etapa se diseñaron específicamente para cada plataforma.

macOS

Un AppleScript descarga un binario en /Library/Caches/com.apple.act.mond, imitando deliberadamente la convención de nombres de los demonios en segundo plano de Apple para pasar desapercibido. Una vez instalado, el RAT:

• Genera un ID de víctima único de 16 caracteres

• Recopila la huella digital del sistema: nombre del host, nombre de usuario, versión de macOS, horas de inicio e instalación, arquitectura de CPU (mac_arm o mac_x64) y procesos en ejecución

• Envía señales al C2 cada 60 segundos usando una cadena User-Agent falsa de IE8/Windows XP

• Acepta cuatro comandos del atacante:

  • peinject: recibe un binario codificado en Base64 desde el C2, lo decodifica, lo escribe en un archivo temporal oculto (por ejemplo, /private/tmp/.XXXXXX), aplica una firma de código ad hoc mediante codesign --force --deep --sign - para evadir Gatekeeper y lo ejecuta

  • runscript: ejecuta comandos arbitrarios de shell mediante /bin/sh o archivos AppleScript con osascript

  • rundir: enumera los metadatos del sistema de archivos en /Applications, ~/Library y ~/Application Support

  • kill: termina el proceso del RAT

Windows

Un descargador VBScript copia el binario de PowerShell en %PROGRAMDATA%\wt.exe (haciéndose pasar por Windows Terminal) y ejecuta un RAT oculto de PowerShell con indicadores para omitir la política de ejecución.

Linux

Se descarga un RAT de Python en /tmp/ld.py y se inicia como proceso en segundo plano huérfano mediante nohup python3, separándolo de la sesión de terminal que lo inició.

Otros paquetes comprometidos

Se observó que otros dos paquetes distribuían la dependencia maliciosa plain-crypto-js:

• @qqbrowser/openclaw-qbot@0.0.130: incluye un axios@1.14.1 alterado con la dependencia inyectada (SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776)

• @shadanai/openclaw (versiones 2026.3.31-1, 2026.3.31-2): incluye directamente plain-crypto-js (SNYK-JS-SHADANAIOPENCLAW-15850775)

Estos paquetes secundarios sugieren que existía una infraestructura coordinada del atacante o que se estaba usando activamente el paquete malicioso plain-crypto-js en campañas relacionadas.

Quiénes están realmente en riesgo

El período de publicación de tres horas (00:21 a 03:29 UTC) es la principal limitación. El riesgo es mayor para:

• Pipelines de CI/CD que no fijan las versiones de las dependencias y ejecutan npm install según un cronograma o al hacer un commit, sobre todo los que se ejecutan durante la noche o temprano por la mañana en UTC.

• Desarrolladores que ejecutaron npm install o npm update durante ese período y descargaron las versiones afectadas.

• Proyectos que dependen de @qqbrowser/openclaw-qbot o @shadanai/openclaw, cuya exposición no depende de la ventana temporal.

Si tu archivo de bloqueo (package-lock.json o yarn.lock) se confirmó antes de que se publicaran las versiones maliciosas y la instalación no lo actualizó, no sufriste el ataque. En este caso, los archivos de bloqueo son tu primera línea de defensa.

Las versiones maliciosas se eliminaron del registro de npm. Sin embargo, cualquiera que las haya instalado durante ese período debe asumir que su sistema quedó completamente comprometido: el RAT estaba activo, enviaba señales y podía ejecutar cargas posteriores arbitrarias.

Remediación con Snyk y cómo verificar tu exposición

Si usas Snyk o eres cliente, cualquiera de las distintas integraciones de Snyk te alertará sobre los proyectos que incluyan la versión comprometida y maliciosa de la dependencia axios, ya sea mediante la CLI de Snyk, la integración de la aplicación de Snyk u otro medio.

La base de datos de Snyk incluye entradas para SNYK-JS-AXIOS-15850650 y SNYK-JS-PLAINCRYPTOJS-15850652, por lo que snyk test marcará las versiones afectadas y la dependencia transitiva maliciosa.

Además, si tienes el plan Enterprise, verás un informe Zero Day en la aplicación, similar a los informes de incidentes de seguridad de día cero anteriores, como LiteLLM, Shai-Hulud y otros. Este informe te ofrece una vista de todo el sistema para encontrar fácilmente los proyectos y repositorios afectados que tienen la dependencia vulnerable de axios:

Si todavía no usas Snyk, hay un plan gratuito y puedes empezar fácilmente a auditar tu entorno para detectar un posible compromiso de axios u otros problemas de seguridad de la siguiente manera:

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

Para usuarios de Bun: solución alternativa con Snyk (al momento de escribir esto, la compatibilidad nativa con bun.lock en la CLI de Snyk es limitada):

La solución alternativa recomendada es generar un archivo de bloqueo compatible con yarn.lock usando la marca integrada -y de Bun, que Snyk puede analizar:

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

También puedes seguir cualquiera de los pasos a continuación para determinar si te afectó el compromiso de axios:

Paso 1: Revisa el archivo de bloqueo para encontrar las versiones afectadas

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

Paso 2: Busca la dependencia maliciosa

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

Paso 3: Busca instalaciones en tiempo de ejecución de Bun de la dependencia maliciosa de axios

Si usas Bun, revisa tu bun.lock (archivo de bloqueo de texto, Bun v1.1 o posterior):

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

También busca la dependencia transitiva maliciosa:

grep 'plain-crypto-js' bun.lock

Nota: Las versiones anteriores de Bun generan un bun.lockb binario. Para inspeccionarlo, primero conviértelo:

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

Paso 4: Busca IOC en los sistemas comprometidos

Si crees que una máquina ejecutó npm install durante el período afectado, busca estos indicadores:

Más recomendaciones de remediación para administradores de paquetes npm

Si no te afectó (medidas preventivas):

1. Fija axios en una versión segura conocida en tu package.json. Cualquier versión que no sea 1.14.1 ni 0.30.4 es segura.

2. Confirma tu archivo de bloqueo y asegúrate de que CI use npm ci (no npm install) para garantizar la integridad del archivo de bloqueo.

3. Agrega plain-crypto-js a una lista de bloqueo en tu administrador de paquetes o herramienta de seguridad.

Considera habilitar --ignore-scripts para las instalaciones de npm en entornos de CI donde no se necesiten los hooks del ciclo de vida:

npm ci --ignore-scripts

Esto impide por completo que se ejecuten los scripts postinstall y habría bloqueado este vector de ataque. Ten en cuenta que puede interrumpir paquetes que necesitan legítimamente pasos posteriores a la instalación (por ejemplo, los complementos nativos).

Además, considera usar e implementar en los equipos de desarrollo el proyecto de código abierto npq, que agrega verificaciones previas de seguridad y estado antes de instalar dependencias.

Por último, te recomendamos revisar y consultar estas prácticas recomendadas de seguridad para npm, recopiladas públicamente.

Si te afectó (asume que hubo una intrusión):

1. Contén la amenaza de inmediato: Aísla todos los sistemas que ejecutaron npm install durante el período afectado.

2. Rota todos los secretos: Considera comprometidas todas las credenciales de la máquina afectada: claves de API, claves SSH, credenciales de la nube, tokens de npm y tokens de GitHub. No las rotes en el mismo lugar; revócalas y emite nuevas.

3. Busca movimiento lateral: Revisa los registros en busca de conexiones salientes a sfrclak[.]com o 142.11.206.73. Si el RAT estaba activo, el atacante tenía capacidad para ejecutar código arbitrario y pudo haber enumerado o exfiltrado más información.

4. Reconstruye los entornos: No intentes limpiar los sistemas comprometidos. Reconstrúyelos a partir de una instantánea o imagen base que sepas que está limpia.

5. Audita los pipelines de CI: Revisa los registros de compilación del período afectado del 31 de marzo de 2026 (UTC) para determinar qué pipelines instalaron las versiones afectadas.

La perspectiva general: seguridad de las cuentas de mantenedores

Este ataque sigue un patrón ya conocido: comprometer la cuenta de un mantenedor legítimo, publicar una versión maliciosa de un paquete de confianza y aprovechar la confianza implícita del ecosistema en los paquetes registrados. Hemos visto esta estrategia contra el plugin Prettier de ESLint, contra varios paquetes de un desarrollador prolífico mediante phishing y contra la campaña Shai-Hulud, que comprometió más de 600 paquetes.

Lo que hace que Axios sea particularmente significativo es su alcance: 100 millones de descargas semanales significan que incluso una ventana maliciosa de dos horas representa un radio de impacto potencial enorme. El atacante también demostró una sofisticación operativa considerable: preparó la dependencia maliciosa con anticipación, usó un historial de versiones «limpio», ofuscó el dropper dos veces, creó RAT específicos para cada plataforma e implementó la aut eliminación para borrar rastros. Esto no fue un ataque oportunista

Para las organizaciones que dependen del código abierto a gran escala, la lección no es dejar de usar npm ni desconfiar de todas las dependencias. Se trata de entender qué controles de la cadena de suministro habrían detectado este ataque: exigir el uso de archivos de bloqueo, auditar los scripts postinstall y monitorear en tiempo de ejecución la creación inesperada de procesos o las conexiones de red salientes desde los entornos de compilación. Vale la pena volver a consultar la guía de Snyk para prevenir ataques a la cadena de suministro de npm y las consideraciones de seguridad de los archivos de bloqueo en el contexto de este incidente.

Si quieres entender esta clase de ataque a nivel conceptual, Snyk Learn tiene una lección específica sobre el compromiso de paquetes legítimos que explica los patrones de ataque y los controles de defensa.

Cronología