
@ Mistral AI
El ataque a la cadena de suministro de Axios (2026): Importancia del análisis de dependencias
Tabla de contenidos
¿Qué ocurrió con Axios?1. Cronología del ataque2. Mecanismo de infección3. Impacto y alcanceEstado actual del CVEIdentificadores y referencias¿Existe un CVE oficial?Recomendaciones de mitigaciónLecciones para el futuro1. Confianza cero en dependencias2. Automatización de la seguridad3. Respuesta rápida y transparenciaConclusiónRecursos adicionalesAnálisis de dependencias con AiSecBox1. Detección de versiones comprometidas2. Escaneo de dependencias transitivasEl 31 de marzo de 2026, el ecosistema de desarrollo JavaScript sufrió uno de los ataques a la cadena de suministro más sofisticados de los últimos años: dos versiones maliciosas del paquete Axios (1.14.1 y 0.30.4) fueron publicadas en el registro npm, inyectando un Remote Access Trojan (RAT) multiplataforma a través de una dependencia oculta llamada plain-crypto-js@4.2.1. El ataque, atribuido a un grupo norcoreano (UNC1069), demostró cómo incluso herramientas de confianza pueden convertirse en vectores de compromiso masivo.
En este artículo, analizamos el ataque, el estado actual del CVE, y cómo AiSecBox puede detectar y mitigar riesgos similares mediante el escaneo de versiones concretas de dependencias frente a CVEs conocidos.
¿Qué ocurrió con Axios?
1. Cronología del ataque
- 30 de marzo de 2026: El atacante compromete la cuenta npm del mantenedor principal de Axios (
jasonsaayman), cambiando el correo electrónico asociado aifstap@proton.mepara bloquear el acceso legítimo. - 31 de marzo de 2026, 00:21 UTC: Se publica
axios@1.14.1con la dependencia maliciosaplain-crypto-js@4.2.1. - 31 de marzo de 2026, 01:00 UTC: Se publica
axios@0.30.4, también con el mismo payload. - Ventana de exposición: Las versiones maliciosas estuvieron disponibles durante aproximadamente 3 horas antes de ser eliminadas por npm, pero fueron descargadas por miles de pipelines CI/CD y entornos de desarrollo en todo el mundo.
El atacante desplegó tres implementaciones paralelas del mismo RAT (Windows, macOS y Linux), todas con el mismo protocolo C2 y comportamiento de baliza. Esto no son tres herramientas diferentes, sino un único framework de implantación multiplataforma con implementaciones nativas (Elastic Security Labs).
2. Mecanismo de infección
- Inyección de dependencia: Las versiones maliciosas de Axios incluían
plain-crypto-js@4.2.1como dependencia de runtime. Esta dependencia no existe en versiones legítimas de Axios (que solo tienenfollow-redirects,form-datayproxy-from-env). - Postinstall hook: Al ejecutar
npm install, el scriptsetup.jsdeplain-crypto-jsse activaba automáticamente, descargando y ejecutando el RAT en el sistema afectado. - Evasión de detección: El script usaba obfuscación en dos capas y simulaba tráfico legítimo de npm para evitar sospechas.
3. Impacto y alcance
- 100 millones de descargas semanales: Axios es una de las bibliotecas más usadas en JavaScript, presente en millones de aplicaciones y pipelines CI/CD.
- Compromiso en cadena: Incluso sistemas que no instalaron Axios directamente pudieron verse afectados si otra dependencia en su entorno lo incluía como dependencia transitiva.
- Robo de credenciales: El RAT estaba diseñado para exfiltrar secretos de CI/CD, claves SSH, tokens de npm, y credenciales de nube.
Estado actual del CVE
Identificadores y referencias
- GHSA-fw8c-xr5c-95f9: Advisory publicado en GitHub para las versiones comprometidas de Axios.
- MAL-2026-2306: Identificador de malware asignado por la comunidad de seguridad.
- Atribución: Google Threat Intelligence Group (GTIG) atribuyó el ataque al grupo norcoreano UNC1069, vinculado a actividades de cibercrimen financiero y espionaje.
¿Existe un CVE oficial?
A abril de 2026, no se ha asignado un CVE oficial en la base de datos de MITRE para este incidente específico. Sin embargo, se recomienda seguir los advisories de GitHub y las guías de mitigación publicadas por Elastic, Google, y StepSecurity, que incluyen:
- Indicadores de Compromiso (IOCs):
- Dominio C2:
sfrclak[.]com(IP: 142.11.206.73, puerto 8000). - Hashes de los archivos maliciosos:
plain-crypto-js@4.2.1: consultar IOCs completos aquí.
- User-Agent anómalo:
mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)(simula Internet Explorer 8 en Windows XP, altamente sospechoso en 2026).
- Dominio C2:
Recomendaciones de mitigación
- Revertir a versiones seguras:
- Para usuarios de Axios 1.x:
npm install axios@1.14.0 - Para usuarios de Axios 0.x:
npm install axios@0.30.3
- Eliminar caches y lockfiles:
rm -rf node_modules package-lock.json
npm cache clean --force
npm install
- Rotar credenciales: Todas las credenciales expuestas en entornos donde se instalaron las versiones maliciosas deben considerarse comprometidas.
- Monitoreo de red: Bloquear tráfico saliente a
sfrclak[.]comy la IP142.11.206.73.
Lecciones para el futuro
1. Confianza cero en dependencias
- No confíes en el nombre del paquete: Incluso paquetes legítimos como Axios pueden ser comprometidos.
- Usa SHAs en lugar de tags: En tu
package.json, especifica versiones con su hash de commit para evitar que un atacante sobrescriba un tag.
2. Automatización de la seguridad
- Herramientas como AiSecBox son críticas para detectar anomalías en tiempo real, especialmente en entornos CI/CD donde la velocidad de desarrollo puede opacar los riesgos de seguridad.
3. Respuesta rápida y transparencia
- La comunidad respondió rápidamente, pero la ventana de 3 horas fue suficiente para causar daño. La automatización en la detección y respuesta es clave.
Conclusión
El ataque a Axios es un recordatorio de que la cadena de suministro de software es tan fuerte como su eslabón más débil. Herramientas como AiSecBox, que analizan versiones concretas de dependencias frente a CVEs y advisories, son esenciales para mitigar riesgos en un ecosistema donde los ataques son cada vez más sofisticados y dirigidos.
Recursos adicionales
- Advisory de GitHub (GHSA-fw8c-xr5c-95f9)
- Análisis técnico de Elastic Security Labs
- Guía de remediación de SOCRadar
- Script de escaneo para detectar compromiso
Análisis de dependencias con AiSecBox
1. Detección de versiones comprometidas
AiSecBox ofrece a tu agente de IA herramientas especializadas en el escaneo de las versiones de dependencias en tu proyecto frente a bases de datos de CVEs y advisories conocidos.
2. Escaneo de dependencias transitivas
AiSecBox no solo revisa las dependencias directas, sino también las transitivas (dependencias de dependencias). Por ejemplo:
- Si tu proyecto depende de
@shadanai/openclaw, que a su vez incluye una versión comprometida de Axios en sunode_modules, AiSecBox lo detectaría y alertaría sobre el riesgo.