DEV Community

Cover image for Ataque a la Cadena de Suministro de axios@1.14.1: Qué Hacer Ahora
Roobia
Roobia

Posted on • Originally published at apidog.com

Ataque a la Cadena de Suministro de axios@1.14.1: Qué Hacer Ahora

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.

Prueba Apidog hoy

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, sigue los pasos de este artículo antes de tu próximo despliegue.

Cronología del ataque

30 de marzo de 2026 — 23:59:12 UTC: Se publica el paquete malicioso plain-crypto-js@4.2.1 en npm desde una cuenta con nrwise@proton.me. Una versión anterior limpia (4.2.0) había sido publicada 18 horas antes como typosquat de la legítima crypto-js.

31 de marzo de 2026 — 00:05:41 UTC: Socket detecta automáticamente 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: Se publica axios@1.14.1 en npm, incluyendo plain-crypto-js@4.2.1 como dependencia. Esta versión no aparece en las etiquetas oficiales del repositorio de GitHub de axios. La última etiqueta legítima sigue siendo v1.14.0.

31 de marzo de 2026 — mañana: Se reporta públicamente la incidencia #10604 en GitHub, confirmando que axios@1.14.1 y axios@0.30.4 están comprometidas. Los mantenedores no pueden revocar el acceso del atacante de inmediato, ya que la cuenta comprometida tiene permisos de npm más altos.

31 de marzo de 2026: Ambas versiones comprometidas son retiradas de npm. Los mantenedores de Axios revocan tokens, endurecen controles y analizan cómo se explotó un token de npm de larga duración para obtener acceso de publicación no autorizado.

Cómo funcionó el ataque

El ataque explotó un token npm de larga duración junto con la publicación de confianza. Tras comprometer las credenciales de un mantenedor, el atacante usó el token para publicar una versión fuera del proceso normal.

  • plain-crypto-js@4.2.1 fue introducido como dependencia, simulando ser una utilidad legítima.
  • La versión 4.2.0 limpia estableció historial para reducir sospechas.

El análisis de Socket identificó una carga útil de múltiples etapas:

  1. Ejecución: Al instalar el paquete, se ejecuta código (mediante scripts npm) para instalar una segunda carga útil.
  2. Despliegue de RAT: Se instala un troyano de acceso remoto que crea una puerta trasera persistente.
  3. Exfiltración: El RAT puede ejecutar comandos shell arbitrarios recibidos de un servidor C2, leer variables de entorno y secretos, y enviar datos del sistema.

El RAT persiste tras reinicios, por lo que la eliminación del paquete npm no es suficiente. Es necesario buscar y eliminar el RAT explícitamente.

¿Estoy afectado?

Posibles indicadores de compromiso:

  • Ejecutaste npm install axios o npm install (con axios en package.json) entre el 30 de marzo, 23:59 UTC y el 31 de marzo de 2026, mediodía UTC.
  • node_modules/axios/package.json muestra la versión 1.14.1 o 0.30.4.
  • Tu package-lock.json o yarn.lock resuelve axios a 1.14.1 o 0.30.4.

Verifica con los siguientes comandos:

# 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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verifica la versión instalada:

npm list axios
# Debería mostrar 1.14.0 o superior (una vez que se publique una versión limpia 1.14.x)
Enter fullscreen mode Exit fullscreen mode

2. Si instalaste la versión comprometida

No trates esto como una simple actualización de dependencia. Procede así:

  • 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 exfiltra información sensible.
  • Audita las conexiones de red salientes del período afectado — busca conexiones desconocidas.
  • Escanea en busca de persistencia: revisa cron jobs, scripts de inicio y servicios systemd agregados alrededor del compromiso.
  • Re-imagen la máquina si es runner CI o servidor de producción. Para laptops de desarrollo, considera las credenciales como comprometidas y rota todo antes de volver a usarla.

3. Audita tus pipelines de CI/CD

Si tu pipeline de CI ejecutó npm install durante el período afectado, tu entorno puede estar 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 estén limpios
npm list axios plain-crypto-js
Enter fullscreen mode Exit fullscreen mode

Rota cualquier secreto al que tu pipeline de CI tenga acceso: claves de despliegue, credenciales cloud, 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 tiene 1.14.1, regenéralo:

rm package-lock.json
npm install
Enter fullscreen mode Exit fullscreen mode

Confirma que el nuevo archivo resuelva axios a una versión segura antes de hacer commit.

Usando Apidog para auditar tus llamadas a la API de axios

Si usas axios como cliente HTTP, Apidog te ayuda a comprobar que tu integración sigue enviando las solicitudes correctas tras la actualización.

  1. Actualiza a axios@1.14.0.
  2. Importa tus endpoints en Apidog y ejecuta una verificación de regresión para confirmar que el comportamiento no ha cambiado.
  3. Usa aserciones para validar que las respuestas no contienen campos inyectados ni headers extraños: 
// 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;
});
Enter fullscreen mode Exit fullscreen mode

Ejecuta tu suite completa de pruebas con la versión actualizada en Apidog para obtener una línea base documentada antes de desplegar 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 sigue un patrón recurrente:

  • event-stream (2018): Añadido código malicioso para robar carteras de bitcoin.
  • ua-parser-js (2021): Instalaba un criptominero y un ladrón de contraseñas.
  • node-ipc (2022): Código destructivo dirigido a ciertas IPs.
  • xz utils (2024): Puerta trasera en biblioteca de compresión de Linux.
  • axios (2026): Credenciales comprometidas usadas para publicar un RAT vía dependencia maliciosa.

El problema subyacente: la confianza recae en la cuenta de publicación, no en el código. Si las credenciales de un mantenedor son comprometidas, el atacante obtiene acceso total.

Medidas de mitigación recomendadas

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
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 se filtra un token
Leer archivos de bloqueo en PRs Detecta cambios inesperados de dependencias en la revisión de código

El equipo de axios ha reconocido que los tokens npm de larga duración contribuyeron al incidente y está implementando controles más estrictos. La solución debe ser adoptada por el ecosistema entero.

Indicadores de Compromiso (IOCs)

Según Socket:

  • Paquetes maliciosos: plain-crypto-js@4.2.1, axios@1.14.1, axios@0.30.4
  • Correo del publicador: nrwise@proton.me
  • Comportamiento: Conexiones de red al instalar 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 infección, reporta a security@npmjs.com y conserva los registros.

Conclusión

El compromiso de axios 1.14.1 demuestra que la seguridad de las dependencias es un proceso continuo, no una revisión puntual. Bloquea versiones, ejecuta análisis de comportamiento en tu CI, rota credenciales si hay incidentes y revisa los archivos de bloqueo en cada PR.

Si necesitas restablecer la confianza en tu integración API tras actualizar axios, Apidog ofrece escenarios de prueba, aserciones y mocking para validar el comportamiento de tu cliente HTTP antes de desplegar.

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 con un RAT capaz de ejecutar comandos remotos, exfiltrar secretos y persistir tras reinicios.

¿Cómo sé si instalé la versión comprometida?

Ejecuta npm list axios — si sale 1.14.1 o 0.30.4, estás afectado. Verifica también npm list plain-crypto-js — si 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. Si instalaste la versión comprometida, rota todos los secretos y audita la máquina.

¿Cómo pudo el atacante publicar en npm sin ser mantenedor?

Probablemente comprometió las credenciales de un mantenedor y explotó un token npm de larga duración. El equipo de axios está investigando y endureciendo los controles.

¿Cuál es la diferencia entre esto y una vulnerabilidad regular?

Una vulnerabilidad es un fallo en código legítimo. Un ataque a la cadena de suministro introduce código malicioso a través del canal de publicación. El código comprometido nunca estuvo en el repo de GitHub de axios; fue inyectado directamente en 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 herramientas como Socket.dev, habilita 2FA en npm, usa tokens de corta duración y audita los cambios de archivos de bloqueo en revisiones de código.

Top comments (0)