TL;DR
El 30 y 31 de marzo de 2026, las versiones 1.14.1 y 0.30.4 de axios fueron comprometidas en npm con una dependencia maliciosa que instala un troyano de acceso remoto (RAT) en las máquinas infectadas. Ambas versiones han sido retiradas. La versión segura es la 1.14.0. Si instalaste axios@1.14.1 o 0.30.4, trata la máquina como comprometida y rota todas las credenciales inmediatamente.
Qué es axios y por qué esto importa
axios tiene 100 millones de descargas semanales en npm. Es el cliente HTTP en innumerables frameworks frontend, servicios backend de Node.js y aplicaciones empresariales. Cuando un paquete tan fundamental es comprometido, el radio de impacto es enorme: los desarrolladores que ejecutaron npm install en una ventana de tiempo estrecha entre el 30 y 31 de marzo instalaron malware en sus máquinas sin saberlo.
Esto no es un riesgo hipotético en la cadena de suministro. Sucedió, se confirmó y la carga útil era grave: un troyano de acceso remoto de múltiples etapas capaz de ejecutar comandos arbitrarios, exfiltrar datos del sistema y persistir en máquinas infectadas.
Si tu equipo usa axios, y usas Apidog para diseñar y probar tus integraciones de cliente HTTP, lee esto antes de tu próximo despliegue.
Cronología del ataque
30 de marzo de 2026 — 23:59:12 UTC: Un paquete malicioso llamado plain-crypto-js@4.2.1 es publicado en npm por una cuenta que usa nrwise@proton.me. Una versión limpia anterior (4.2.0) había sido publicada 18 horas antes como un convincente typosquat de la legítima biblioteca crypto-js.
31 de marzo de 2026 — 00:05:41 UTC: La detección automática de malware de Socket marca plain-crypto-js@4.2.1 como malicioso — seis minutos después de su publicación.
31 de marzo de 2026 — poco después de la medianoche: axios@1.14.1 es publicado en npm, incluyendo plain-crypto-js@4.2.1 como dependencia. La versión no aparece en las etiquetas oficiales del repositorio de GitHub de axios. La etiqueta legítima más reciente sigue siendo v1.14.0.
31 de marzo de 2026 — mañana: Se abre públicamente la incidencia #10604 en GitHub informando de que tanto axios@1.14.1 como axios@0.30.4 están comprometidas. Los mantenedores de Axios confirman que inicialmente no pueden revocar el acceso del atacante — la cuenta comprometida tiene permisos de npm más altos que los mantenedores legítimos.
31 de marzo de 2026: Tanto axios@1.14.1 como axios@0.30.4 son retiradas de npm. Los mantenedores de Axios comienzan a revocar tokens, a endurecer los controles de publicación y a investigar cómo un token de npm de larga duración fue explotado para obtener acceso de publicación no autorizado.
Cómo funcionó el ataque
El ataque explotó una brecha en el flujo de trabajo de publicación de axios: un token npm de larga duración que se había utilizado junto con la publicación de confianza. El atacante, probablemente después de comprometer las credenciales de un mantenedor, utilizó este token para publicar una nueva versión fuera del proceso de lanzamiento normal.
La nueva versión introdujo plain-crypto-js@4.2.1 como dependencia. El nombre del paquete fue diseñado para parecer una utilidad de criptografía legítima; la versión limpia anterior 4.2.0 estableció un breve historial para reducir las sospechas.
Dentro de plain-crypto-js@4.2.1, el análisis de Socket encontró una carga útil de múltiples etapas:
- Etapa 1 — Ejecución: El paquete ejecuta código en el momento de la instalación (a través de scripts de ciclo de vida de npm) para instalar una carga útil secundaria.
- Etapa 2 — Despliegue de RAT: La carga útil instala un troyano de acceso remoto que abre una puerta trasera persistente.
- Etapa 3 — Exfiltración: El RAT es capaz de ejecutar comandos de shell arbitrarios enviados desde un servidor C2, leer variables de entorno y secretos del sistema de archivos, y enviar datos del sistema a través de la red.
El RAT persiste a través de los reinicios, lo que significa que las máquinas que instalaron la versión comprometida siguen en riesgo incluso después de que se elimine el paquete npm, a menos que el RAT sea buscado y eliminado explícitamente.
¿Estoy afectado?
Estás potencialmente afectado si:
- Ejecutaste
npm install axiosonpm install(con axios enpackage.json) entre aproximadamente el 30 de marzo, 23:59 UTC y el 31 de marzo de 2026, mediodía UTC. - Tu
node_modules/axios/package.jsonmuestra la versión1.14.1o0.30.4. - Tu
package-lock.jsonoyarn.lockresuelve axios a1.14.1o0.30.4.
Comprueba inmediatamente:
# Comprobar versión instalada
npm list axios
# Comprobar archivo de bloqueo
grep '"axios"' package-lock.json | head -5
# Comprobar la presencia de plain-crypto-js
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTADO" || echo "No encontrado"
Si plain-crypto-js está presente en tu node_modules, ejecutaste la versión maliciosa.
Qué hacer ahora mismo
1. Actualiza axios inmediatamente
npm install axios@1.14.0
# o fija la última versión segura
npm install axios@latest
Verifica:
npm list axios
# Debería mostrar 1.14.0 o superior (una vez que se publique una versión limpia 1.14.x)
2. Si instalaste la versión comprometida
No trates esto como una actualización de dependencia rutinaria. Trata la máquina como comprometida:
- Rota todos los secretos accesibles desde esa máquina: claves API, credenciales de base de datos, claves SSH, tokens de proveedor de nube, variables
.env. - Verifica tus variables de entorno — el RAT apunta específicamente a secretos en el entorno del proceso y el sistema de archivos.
- Audita las conexiones de red salientes del período afectado — busca conexiones a IPs desconocidas.
- Escanea en busca de persistencia — verifica trabajos cron, scripts de inicio y servicios systemd agregados alrededor de la ventana de compromiso.
- Re-imagen la máquina si es un CI runner o un servidor de producción que tenía la versión comprometida instalada. Si es una laptop de desarrollador, considera las credenciales como quemadas y rota todo antes de considerarla limpia.
3. Audita tus pipelines de CI/CD
Si tu pipeline de compilación ejecutó npm install durante el período, tu entorno de CI pudo haber sido comprometido. Verifica:
# Revisa los logs de compilación para el período afectado
# Busca axios@1.14.1 en cualquier salida de instalación
# Verifica que los node_modules del CI actual estén limpios
npm list axios plain-crypto-js
Rota cualquier secreto al que tu pipeline de CI tenga acceso: claves de despliegue, credenciales de proveedor de nube, tokens de registro.
4. Verifica tu archivo de bloqueo
Los archivos de bloqueo (package-lock.json, yarn.lock) deben fijar versiones exactas. Si tu archivo de bloqueo tiene 1.14.1, regenéneralo:
# Eliminar y regenerar
rm package-lock.json
npm install
Verifica que el nuevo archivo de bloqueo resuelva axios a una versión segura antes de confirmarlo.
Usando Apidog para auditar tus llamadas a la API de axios
Si usas axios como tu cliente HTTP para llamar a APIs, Apidog puede ayudarte a verificar que tu integración sigue enviando las solicitudes correctas después de la actualización de la dependencia.
Después de actualizar a axios@1.14.0, importa tus endpoints API existentes en Apidog y ejecuta una rápida verificación de regresión para confirmar que el comportamiento no ha cambiado. Esto es especialmente útil si te preocupa que la versión maliciosa pueda haber alterado las cargas útiles de las solicitudes o respuestas — las aserciones de respuesta de Apidog te permiten validar valores de campo exactos, encabezados y códigos de estado:
// Aserción post-respuesta de Apidog
pm.test("La respuesta está limpia — sin campos inyectados", () => {
const body = pm.response.json();
pm.expect(body).to.not.have.property('__injected');
pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});
Ejecutar tu suite completa de pruebas contra la versión actualizada de axios en Apidog te proporciona una línea base limpia documentada antes de implementar en producción.
Prueba Apidog gratis para configurar pruebas de regresión de cliente HTTP.
Por qué los ataques a la cadena de suministro en npm son difíciles de detener
El ataque a axios no es una anomalía. Es un patrón:
- event-stream (2018): Un mantenedor malicioso añadió una carga útil que apuntaba a carteras de bitcoin. 8 millones de descargas semanales.
- ua-parser-js (2021): Comprometido para instalar un criptominero y un ladrón de contraseñas.
- node-ipc (2022): El mantenedor añadió intencionadamente código destructivo dirigido a IPs rusas/bielorrusas.
- xz utils (2024): Una campaña de ingeniería social de dos años para instalar una puerta trasera en una biblioteca de compresión central de Linux.
- axios (2026): Credenciales de mantenedor comprometidas utilizadas para publicar un RAT a través de una dependencia maliciosa.
El hilo común: confianza en la cuenta de publicación, no en el código. El modelo de npm otorga acceso de publicación a los mantenedores, y si las credenciales de un mantenedor son comprometidas, el atacante hereda esa confianza.
Medidas de mitigación que realmente ayudan:
| Medida | Lo que hace |
|---|---|
Archivos de bloqueo (package-lock.json) |
Fija versiones exactas, evita actualizaciones silenciosas |
npm audit en CI |
Marca vulnerabilidades conocidas antes del despliegue |
| Socket.dev / Snyk | Análisis de comportamiento — marca paquetes sospechosos incluso antes de que existan CVEs |
| Autenticación de dos factores en npm | Dificulta el compromiso de credenciales |
npm publish con tokens de corta duración |
Limita la ventana de exposición si un token se filtra |
| Leer archivos de bloqueo en PRs | Detecta cambios inesperados de dependencia en la revisión de código |
El equipo de axios ha reconocido desde entonces que los tokens npm de larga duración fueron parte del problema y está implementando controles de publicación más estrictos. Pero la solución debe venir del ecosistema, no solo de paquetes individuales.
Indicadores de Compromiso (IOCs)
Según el análisis de Socket:
- Paquetes maliciosos:
plain-crypto-js@4.2.1,axios@1.14.1,axios@0.30.4 - Correo electrónico del publicador:
nrwise@proton.me - Comportamiento: Conexiones de red en el momento de la instalación de npm, persistencia del RAT, exfiltración de variables de entorno
- Versiones seguras de axios: 1.14.0 y anteriores (excepto 0.30.4), 1.13.x, 1.12.x
Si sospechas de infección, presenta un informe a la seguridad de npm en security@npmjs.com y conserva los registros.
Conclusión
El compromiso de axios 1.14.1 es un recordatorio de que la seguridad de las dependencias no es una auditoría única, sino un proceso continuo. Bloquea tus versiones, ejecuta herramientas de análisis de comportamiento como Socket en tu CI, rota las credenciales cuando algo parezca extraño y mantén tus archivos de bloqueo bajo revisión en la revisión de código.
Si necesitas reconstruir la confianza en tu integración API después de actualizar axios, Apidog te ofrece los escenarios de prueba, aserciones y herramientas de mocking para verificar el comportamiento de tu cliente HTTP antes de implementarlo.
Preguntas frecuentes
¿Qué versiones de axios están comprometidas?axios@1.14.1 y axios@0.30.4. Ambas han sido retiradas de npm. La versión segura es 1.14.0 (o cualquier versión de las líneas 1.13.x, 1.12.x).
¿Qué hace la carga útil maliciosa de axios?Incluye plain-crypto-js@4.2.1, que despliega una carga útil de múltiples etapas que incluye un troyano de acceso remoto (RAT). El RAT puede ejecutar comandos arbitrarios desde un servidor C2 remoto, exfiltrar variables de entorno y secretos, y persistir a través de los reinicios.
¿Cómo sé si instalé la versión comprometida?Ejecuta npm list axios — si muestra 1.14.1 o 0.30.4, estás afectado. También verifica npm list plain-crypto-js — si ese paquete está presente, el código malicioso se ejecutó en tu máquina.
¿Basta con solo actualizar axios?No. La actualización elimina la dependencia maliciosa en el futuro, pero el RAT ya podría estar instalado y persistiendo en la máquina. Si instalaste la versión comprometida, rota todos los secretos y audita la máquina en busca de mecanismos de persistencia.
¿Cómo pudo el atacante publicar en npm sin ser un mantenedor?El atacante probablemente comprometió las credenciales de un mantenedor y explotó un token npm de larga duración que tenía acceso de publicación. El equipo de axios está investigando y endureciendo los controles de publicación.
¿Cuál es la diferencia entre esto y una vulnerabilidad regular?Una vulnerabilidad es un fallo en un código legítimo. Un ataque a la cadena de suministro introduce código malicioso a través de un canal de publicación de confianza. El código comprometido nunca estuvo en el repositorio de GitHub de axios — fue inyectado directamente en la publicación de npm.
¿Cómo puedo proteger mis proyectos de futuros ataques a la cadena de suministro?Usa archivos de bloqueo, ejecuta npm audit en CI, añade una herramienta como Socket.dev para análisis de comportamiento, habilita la 2FA en las cuentas de npm, usa tokens de publicación de corta duración y audita las diferencias de tu archivo de bloqueo en la revisión de código.