Si tu proyecto usa axios — y si trabajás con JavaScript, probablemente lo uses — esto te concierne directamente.
En la madrugada del 31 de marzo (UTC), un atacante comprometió la cuenta npm del mantenedor principal de axios, publicó dos versiones envenenadas de la librería, y las removió antes de que la mayoría de los equipos en América llegara a su oficina. La ventana de exposición fue de aproximadamente tres horas. Axios tiene más de 100 millones de descargas semanales. La escala del riesgo potencial es difícil de subestimar.
Qué Pasó Exactamente
El atacante no modificó el código fuente de axios. En cambio, comprometió la cuenta npm de jasonsaayman, el mantenedor principal, cambió el email registrado por una dirección de ProtonMail para bloquearlo, y publicó dos releases manualmente via CLI — completamente saltando el pipeline de CI/CD de GitHub Actions del proyecto.
La dependencia maliciosa fue preparada con 18 horas de anticipación. Se pre-construyeron tres payloads separados para tres sistemas operativos. Ambas branches de release fueron afectadas en un intervalo de 39 minutos.
Las versiones comprometidas son axios@1.14.1 y axios@0.30.4. Ambas inyectan una nueva dependencia: plain-crypto-js@4.2.1, un paquete que nunca existió antes del 30 de marzo y que no es importado en ninguna parte del código real de axios. Su único propósito es ejecutar un script postinstall que actúa como dropper de un RAT cross-platform, apuntando a macOS, Windows y Linux.
El Mecanismo: Por Qué postinstall Es Tan Peligroso
Cuando corrés npm install, npm ejecuta automáticamente los scripts definidos en package.json de cada dependencia — incluyendo las transitivas. No necesitás importar plain-crypto-js en tu código. No necesitás saber que existe. Basta con que esté en el árbol de dependencias para que su script se ejecute con los privilegios de tu sesión, en tu máquina o en tu runner de CI/CD.
StepSecurity confirmó la operación del malware via análisis en runtime usando su herramienta Harden-Runner: una conexión al dominio C2 fue detectada apenas 1.1 segundos después de correr npm install.
El dropper luego se auto-elimina — borra setup.js y reemplaza el package.json con una versión limpia. Si inspeccionás node_modules/plain-crypto-js después de la instalación, verás un paquete de aspecto completamente inocente. Pero la presencia de esa carpeta es suficiente evidencia de que el dropper se ejecutó.
Qué Hace el RAT
Los payloads de segunda etapa funcionan como RATs livianos que hacen beacon al servidor C2 cada 60 segundos, transmitiendo inventario del sistema y esperando comandos. Los tres variantes implementan capacidades similares: ejecución de shell remoto, inyección de binarios, navegación de directorios, listado de procesos y reconocimiento del sistema.
En Windows, el RAT establece persistencia vía una clave Run en el registro. En Linux — y esto es revelador — no establece persistencia: los investigadores de Huntress interpretan esto como evidencia de que el atacante entiende que los targets Linux son principalmente CI/CD runners y contenedores, donde la persistencia no es necesaria porque el valor está en los secretos accesibles durante el build.
Google Threat Intelligence Group (GTIG) atribuyó el ataque a un actor norcoreano rastreado como UNC1069, señalando que los hackers norcoreanos tienen experiencia profunda en ataques a cadenas de suministro, que han usado históricamente para robar criptomonedas.
Cómo Saber Si Fuiste Afectado
Revisá tu lockfile:
# package-lock.json
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'
# yarn.lock
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'
# Buscá la dependencia maliciosa directamente
npm ls plain-crypto-js
find node_modules -name "plain-crypto-js" -type d
Buscá artefactos del RAT en el sistema:
- macOS:
/Library/Caches/com.apple.act.mond - Windows:
%PROGRAMDATA%\wt.exe - Linux:
/tmp/ld.py
Si tu lockfile fue commiteado antes de que se publicaran las versiones maliciosas y tu instalación no lo actualizó, no fuiste afectado.
Qué Hacer Si Estás Comprometido
Si se encuentran artefactos del RAT: tratá el sistema como completamente comprometido. No intentes limpiar en el lugar — reconstruí desde un estado conocido como seguro.
Rotá todos los secretos accesibles desde el sistema afectado: npm tokens, claves SSH, credenciales cloud (AWS, GCP, Azure), API keys, y cualquier valor en archivos .env accesibles al momento de la instalación. Auditá tus pipelines de CI/CD para identificar qué runs instalaron las versiones afectadas — la exposición no se limita a máquinas de desarrollo.
Para mitigación general: bajá a axios@1.14.0 o axios@0.30.3, eliminá node_modules/plain-crypto-js, y reinstalá con npm install --ignore-scripts.
Este incidente sigue un patrón que viene acelerándose en 2026: cuentas de mantenedores comprometidas para publicar versiones envenenadas de paquetes de alta confianza. No es el primero y no será el último. La pregunta no es si tu ecosistema de dependencias es un vector de ataque viable — claramente lo es. La pregunta es qué controles tenés en lugar para detectarlo cuando ocurra.
Fuentes: StepSecurity · Snyk · Wiz · Huntress · Socket · Help Net Security