Ataque npm a Axios: cómo una cuenta de mantenedor secuestrada amenazó a millones de desarrolladores

8 Min. de lectura

El 31 de marzo de 2026, la empresa de seguridad StepSecurity descubrió un troyano de acceso remoto en dos versiones manipuladas del paquete npm Axios, una de las bibliotecas JavaScript más utilizadas en el mundo, con más de 100 millones de descargas semanales. El ataque aprovechó una dependencia falsa, una cuenta de mantenedor secuestrada y un servidor C2 para instalar puertas traseras multiplataforma en máquinas de desarrolladores. Se considera uno de los ataques a la cadena de suministro más sofisticados en la historia del ecosistema npm.

Qué ocurrió

Axios lleva más de diez años siendo una de las bibliotecas JavaScript más populares para peticiones HTTP. Aunque entornos de ejecución modernos como Node.js y Deno ya soportan la API Fetch nativa, millones de desarrolladores siguen prefiriendo Axios por su API más cómoda, la transformación automática de JSON y los interceptores integrados. Esta difusión lo convirtió en un objetivo ideal.

El 30 de marzo de 2026 a las 23:59 UTC, un atacante publicó la versión 4.2.1 del paquete npm plain-crypto-js, un paquete que se asemeja sospechosamente al legítimo y ampliamente utilizado crypto-js. Veintidós minutos después, siguió la versión manipulada 1.14.1 de Axios, etiquetada como «latest». A la 01:00 UTC apareció además la versión 0.30.4, etiquetada como «legacy». Ambas versiones de Axios incluían plain-crypto-js como nueva dependencia en tiempo de ejecución.

El ataque fue cuidadosamente orquestado. Ya 18 horas antes, el atacante había publicado una versión inofensiva 4.2.0 de plain-crypto-js, una versión señuelo que no activó alarmas en los escaneos automatizados. Solo la versión 4.2.1 contenía el código malicioso real.

Normalmente, las versiones de Axios se publican a través de GitHub Actions. Las versiones manipuladas, en cambio, se publicaron directamente mediante una cuenta de npm comprometida. El atacante había tomado el control de la cuenta del principal mantenedor, jasonsaayman, y reemplazado la dirección de correo electrónico registrada por una de Proton Mail. Hasta abril de 2026, no se ha confirmado públicamente cómo se logró el secuestro de la cuenta.

npm eliminó ambas versiones en un plazo de dos a tres horas. En el caso de un paquete con más de 100 millones de descargas semanales, incluso unas pocas horas representan una ventana crítica.

Anatomía del ataque: del script postinstall al servidor C2

El código fuente de Axios en sí no contenía código malicioso. La manipulación se limitó a añadir plain-crypto-js como dependencia en el archivo package.json. Quien solo hubiera auditado el código de Axios no habría encontrado nada. El arma real estaba oculta en la nueva dependencia.

El paquete plain-crypto-js contenía un script postinstall llamado setup.js. En cuanto un desarrollador ejecutaba npm install, se ponía en marcha en segundo plano un JavaScript ofuscado con XOR de dos etapas: el llamado RAT-Dropper. Este actuaba en cuatro fases:

Fase 1 – Reconocimiento del sistema: El script identifica el sistema operativo del equipo objetivo. Se soportan macOS, Windows y Linux.

Fase 2 – Descarga de la carga útil: El dropper establece una conexión con el servidor de comando y control (dominio: sfrclak.com, IP: 142.11.206.73, puerto 8000). Desde allí se descarga un binario específico para cada plataforma.

Fase 3 – Ejecución: El RAT se escribe en el disco duro y se inicia. En macOS se instala como com.apple.act.mond en la caché de la biblioteca y se ejecuta mediante /bin/zsh. En Windows se camufla como wt.exe (Windows Terminal) en %PROGRAMDATA% y utiliza un dropper en VBScript. En Linux se descarga un RAT en Python en /tmp/ld.py y se inicia en segundo plano con nohup.

Fase 4 – Eliminación de huellas: El script postinstall se borra a sí mismo y reemplaza su propio package.json por la versión limpia 4.2.0. Un posterior npm list muestra la versión 4.2.0. Un npm audit no detecta nada sospechoso. La infección está activa, pero es invisible.

Una vez instalado, el RAT tiene acceso a todo lo que se encuentra en el sistema comprometido: credenciales de AWS, claves de API de OpenAI, tokens de GitHub, claves SSH, archivos .env con contraseñas de bases de datos. En entornos CI/CD, las consecuencias pueden ser aún más graves: allí suelen almacenarse credenciales de despliegue, claves de firma y accesos a sistemas de producción. Un servidor de compilación comprometido puede convertirse en la puerta de entrada a toda la infraestructura.

StepSecurity descubrió el ataque a través de su AI Package Analyst y la herramienta de monitorización en tiempo de ejecución Harden-Runner en pipelines de GitHub Actions instrumentadas. La herramienta registra las conexiones de red salientes durante npm install y saltó la alarma cuando se contactó con un servidor C2 desconocido.

«El consejo de seguridad más importante lleva años siendo el mismo: mantén tus paquetes actualizados. Desde hace poco, da la sensación de que precisamente eso es el camino más rápido para ser comprometido.»
– Nota de la redacción

Por qué este ataque marca una nueva calidad

Los ataques a la cadena de suministro en npm no son nuevos. El incidente de event-stream en 2018 pasó desapercibido durante meses y tenía como objetivo carteras de criptomonedas. La vulneración de ua-parser-js en 2021 afectó a un paquete con siete millones de descargas semanales y distribuyó *credential stealers*. El sabotaje de colors.js en 2022 fue una acción de protesta política del propio mantenedor. Cada uno de estos incidentes sacudió el ecosistema, y sin embargo, el ataque a Axios supone una escalada.

La magnitud del objetivo no tiene precedentes: Axios es uno de los diez paquetes npm más utilizados. El radio de impacto de una vulneración exitosa afecta potencialmente a cientos de miles de proyectos y pipelines de CI/CD en todo el mundo.

La sofisticación supera con creces a ataques anteriores. En lugar de insertar código malicioso directamente en el código fuente, el atacante empleó una inyección de dependencias escalonada con activación retardada y borrado automático de huellas. Tras la instalación, el sistema parecía limpio: un camuflaje activo que va mucho más allá de un ocultamiento pasivo. StepSecurity registró el primer contacto con el servidor de comando y control (C2) en tan solo dos segundos tras un *npm install* en un *runner* instrumentado. Sin este monitoreo automatizado, el ataque podría haber pasado desapercibido durante mucho más tiempo.

La comparación con incidentes previos en npm evidencia la escalada: en el ataque a event-stream de 2018, un atacante se hizo con un paquete abandonado mediante ingeniería social y colocó código malicioso durante meses, dirigido a carteras de Bitcoin. En el caso de ua-parser-js de 2021, se secuestró la cuenta del mantenedor y se distribuyó un *credential stealer*, similar al ataque a Axios, pero sin el ocultamiento en múltiples capas ni *payloads* multiplataforma. El sabotaje de colors.js en 2022 fue una acción de protesta consciente del mantenedor, no una vulneración externa.

A esto se suma la atribución: Microsoft Threat Intelligence atribuye el ataque al grupo Sapphire Sleet, mientras que Google Threat Intelligence Group lo vincula a UNC1069. Ambas denominaciones apuntan a actores norcoreanos con motivación financiera. Elastic Security Labs identificó solapamientos del binario para macOS con WAVESHAPER, una *backdoor* norcoreana conocida. De confirmarse esta clasificación, sería el primer caso documentado en el que un actor estatal compromete un paquete npm del *top 100*.

Qué deben hacer ahora los equipos de TI

El compromiso no afecta solo a los desarrolladores de JavaScript. Toda organización que utilice Axios en sus proyectos o pipelines de CI/CD debería priorizar las siguientes medidas:

1. Comprobar versiones: Revisar todos los archivos package.json y archivos de bloqueo en busca de axios@1.14.1 o axios@0.30.4. Realizar un downgrade inmediato a 1.14.0 o 0.30.3, respectivamente.
2. Analizar node_modules: Buscar el paquete plain-crypto-js. Si está presente: tratar el sistema como comprometido.
3. Verificar artefactos RAT: En macOS, buscar /Library/Caches/com.apple.act.mond; en Windows, %PROGRAMDATA%/wt.exe; en Linux, /tmp/ld.py.
4. Rotar credenciales: Renovar inmediatamente todas las claves API, tokens y credenciales de acceso en los sistemas afectados: AWS, OpenAI, GitHub, archivos .env.
5. Bloquear C2: Bloquear la IP 142.11.206.73 y el dominio sfrclak.com en el perímetro de la red.
6. Proteger CI/CD: Establecer npm ci –ignore-scripts como estándar. Activar políticas de antigüedad mínima de versiones para evitar la instalación automática de versiones recién publicadas.

La vulnerabilidad estructural persiste

El incidente de Axios pone al descubierto un problema fundamental del ecosistema npm: una sola cuenta con un token de publicación válido puede distribuir código malicioso a millones de sistemas. npm ha avanzado con Trusted Publishers y autenticación basada en OIDC, pero el atacante eludió precisamente este mecanismo al tomar el control de la cuenta del mantenedor.

Para los CISO y los equipos de seguridad de TI, surge una prioridad clara: la seguridad de la cadena de suministro de software debe alcanzar el mismo nivel de importancia que la seguridad de red o de endpoints. El monitoreo automatizado de dependencias, el análisis en tiempo de ejecución en pipelines de CI/CD y políticas estrictas para paquetes de terceros ya no son opcionales.

En concreto, esto significa que toda organización necesita una Software Bill of Materials (SBOM) actualizada, alertas automatizadas ante cambios inusuales en las dependencias y una política clara sobre la rapidez con la que las nuevas versiones de paquetes pueden implementarse en sistemas productivos. Usar archivos de bloqueo de manera consistente, desactivar scripts postinstall en CI/CD por defecto y configurar políticas de antigüedad mínima de versiones son tres medidas que eliminan la mayor parte de esta superficie de ataque. El próximo ataque no se dirigirá contra Axios, pero utilizará el mismo mecanismo.

Preguntas frecuentes

¿Estoy afectado si uso Axios?

Solo si tiene instalada la versión 1.14.1 o 0.30.4. Todas las demás versiones no están afectadas. Revise su package.json y sus archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml).

¿Basta con desinstalar la versión afectada de Axios?

No. Si el RAT ya se ejecutó, se ha copiado en rutas del sistema y ha eliminado el script postinstall. Un downgrade de Axios por sí solo no elimina el troyano. Trate el sistema como comprometido y rote todas las credenciales.

¿Cómo se comprometió la cuenta del mantenedor?

El vector de ataque exacto, a abril de 2026, no está confirmado públicamente. Se sabe que la dirección de correo electrónico registrada en la cuenta npm de jasonsaayman se cambió por una dirección de Proton Mail y que los releases evitaron la pipeline habitual de GitHub Actions.

¿Existe un número CVE para este incidente?

A abril de 2026, no se ha asignado ninguna CVE. Varias empresas de seguridad han documentado el incidente, pero aún no se ha formalizado la asignación de una CVE.

¿Por qué npm no detectó antes las versiones maliciosas?

npm no realiza análisis automatizado de comportamiento al publicar paquetes. Estos se revisan principalmente en busca de firmas de malware conocidas. Un script postinstall que contacta con un servidor externo no es técnicamente inusual: muchos paquetes legítimos utilizan mecanismos similares para pasos de configuración. La detección se produjo gracias a un monitoreo externo, no a los propios mecanismos de protección de npm.

¿Qué puedo hacer para mitigar en general los ataques a la cadena de suministro?

Utilice archivos de bloqueo de manera consistente, ejecute npm ci en lugar de npm install en pipelines de CI/CD, active –ignore-scripts para paquetes no confiables y emplee herramientas de monitoreo en tiempo de ejecución. Una política de antigüedad mínima de versiones evita que las versiones recién publicadas se instalen automáticamente. Además, los equipos deberían mantener una Software Bill of Materials (SBOM) y configurar alertas automatizadas ante cambios en las dependencias.

Fuente de la imagen: Generada por IA (mayo de 2026), certificado C2PA incrustado en la imagen

Sobre el autor: Benedikt Langer

Más artículos de Benedikt Langer