Ataque a axios en npm: 3 horas con malware sin tocar su código
Por MatchCode
¿Instalaste axios a finales de marzo de 2026? En la ventana equivocada, pudiste bajar un troyano sin que el código de la librería cambiara ni una línea. El ataque a axios en npm es un caso de libro de ataque a la cadena de suministro, y entender el porqué te sirve para proteger tus proyectos.
Qué pasó en el ataque a axios en npm
Axios es la librería de JavaScript que medio mundo usa para hablar con servidores. Según Datadog Security Labs y Tenable, tiene más de 100 millones de descargas semanales.
El 30 y 31 de marzo de 2026 se publicaron dos versiones maliciosas: axios@1.14.1 y axios@0.30.4. Estuvieron disponibles unas 3 horas antes de que npm las retirara. Parece poco, pero con ese volumen, 3 horas alcanzan para que mucha gente las instale sin saberlo.
Ni una línea de código cambiada
Los atacantes publicaron desde la cuenta de npm de uno de los mantenedores de axios. Y no modificaron el código de la librería: un diff entre versiones mostraba cero líneas cambiadas. Lo único distinto era una dependencia nueva en el package.json: plain-crypto-js.
La dependencia falsa: plain-crypto-js
plain-crypto-js no era una librería de criptografía real. Era un paquete falso cuyo único trabajo era ejecutar un script de instalación malicioso. Axios ni siquiera la usaba: bastaba con que estuviera en el árbol de dependencias para que npm la descargara.
Por qué npm install ejecuta código sin preguntarte
Este es el porqué real del ataque. Cuando haces npm install:
- npm descarga el paquete y todas sus dependencias a la carpeta node_modules/.
- Lee el package.json de cada una, que es como su ficha técnica.
- Si la ficha trae un script postinstall, npm lo ejecuta solito, sin pedirte permiso.
El postinstall de plain-crypto-js instalaba un troyano. No descargaste solo código: lo ejecutaste.
Qué hacía el troyano
Era un troyano de acceso remoto para Windows, macOS y Linux, según Tom's Hardware, Security Affairs y Elastic. Los atacantes podían controlar el computador de quien instaló el paquete.
El truco final: el malware se borraba solo
- El script de instalación (setup.js, según Elastic e Infinum) se borraba a sí mismo.
- Luego cambiaba su package.json por una copia limpia, sin la línea postinstall.
Si abrías node_modules para revisar, todo se veía normal. La evidencia había desaparecido.
Quién está detrás y qué buscaban
Tenable, Google y Sophos atribuyen el ataque a actores ligados a Corea del Norte: Tenable y Google lo asocian con UNC1069; Sophos lo llama NICKEL GLADSTONE. Según Security Affairs, Dark Reading y SEAL, ese grupo se dedica a robar criptomonedas.
¿Por qué un desarrollador? Porque su computador suele estar lleno de llaves, tokens, contraseñas y archivos .env. Es un objetivo valioso.
Cómo protegerte de ataques como este
Si instalabas con npm install axios --ignore-scripts, ese postinstall nunca se ejecutaba. La bandera le dice a npm que no corra scripts de instalación de ningún paquete. No es mágica (algunos paquetes legítimos los necesitan para compilarse), pero reduce mucho la superficie de ataque.
Además:
- Revisa los cambios en el package.json y el lockfile al actualizar dependencias.
- Si instalaste en esas fechas, revisa tus versiones de axios y rota las credenciales de esa máquina.
Preguntas frecuentes
¿Qué versiones de axios fueron maliciosas?
axios@1.14.1 y axios@0.30.4, publicadas el 30 y 31 de marzo de 2026.
¿Cambiaron el código de axios?
No. Solo agregaron una dependencia falsa, plain-crypto-js, con un script postinstall malicioso.
¿Qué hace la opción --ignore-scripts?
Evita que npm ejecute los scripts de instalación, como postinstall. En este caso habría impedido que el troyano se instalara.
La lección: instalar es ejecutar
No tuvieron que romper axios: les bastó con colarse en sus dependencias. Cuando usted hace npm install, no solo descarga código: también lo ejecuta.
Mira el Short del ataque a axios en YouTube y sigan a MatchCode en YouTube, TikTok e Instagram (@MatchCodeOficial) y en matchcode.dev.