Otro día, otro ataque a la cadena de suministro… pero este duele más
Si pensaban que ya habíamos visto de todo en el mundo de los ataques a la cadena de suministro, el 31 de marzo de 2026 nos trajo una sorpresa que nos dejó a todos con el corazón en un puño. Axios, ese querido cliente HTTP que usamos prácticamente en todos nuestros proyectos JavaScript, fue comprometido. Y no, no fue un simple susto: fue una operación quirúrgica de precisión que nos recuerda que en el ecosistema npm, la confianza es un lujo que no podemos darnos.
¿Qué pasó exactamente?
La historia empieza como una pesadilla de todo mantenedor de código abierto: un atacante logró acceso a la cuenta npm de jasonsaayman, el responsable principal de Axios. Con esas credenciales en mano, el atacante publicó dos versiones maliciosas: la 1.14.1 y la 0.30.4, en un intervalo de apenas 39 minutos. Ambas ramas del proyecto quedaron comprometidas simultáneamente.
Lo más interesante (y aterrador) es que el atacante no modificó ni una sola línea del código fuente de Axios. En su lugar, inyectó una dependencia fantasma llamada plain-crypto-js (versión 4.2.1) que contenía el verdadero payload malicioso. Esta dependencia falsa incluía un script postinstall que se ejecutaba automáticamente durante la instalación y desplegaba un RAT (Remote Access Trojan) multiplataforma capaz de operar en Windows, macOS y Linux.
Un ataque calculado al milímetro
Este no fue un ataque improvisado. Los atacantes demostraron un nivel de planificación que nos debería hacer reflexionar. Dieciocho horas antes de publicar las versiones maliciosas, el atacante publicó una versión limpia de plain-crypto-js en npm para generar antecedentes y evitar que saltaran las alarmas automatizadas de los sistemas de seguridad. Las versiones comprometidas se publicaron justo antes de medianoche del domingo, horario que maximizaba el tiempo de exposición antes de que los responsables pudieran reaccionar.
Las versiones maliciosas estuvieron disponibles en npm durante aproximadamente tres horas antes de ser eliminadas. En ese intervalo, la empresa de seguridad Huntress detectó al menos 135 sistemas contactando con el servidor del atacante. En cada uno de ellos, el troyano realizó un reconocimiento completo del sistema: directorios, procesos activos, unidades de disco, y envió toda esa información al servidor remoto.
¿Qué hacía exactamente el malware?
El RAT desplegado era una obra de ingeniería multiplataforma bastante sofisticada. En Windows, el malware lograba persistencia en el sistema, lo que significa que podía sobrevivir a reinicios y mantener el acceso remoto de forma permanente. En Linux y macOS, el ataque utilizaba cargas útiles basadas en Python para escanear archivos del sistema y recopilar información sensible.
Según el análisis de Elastic Security Labs, el RAT estaba diseñado como una herramienta unificada capaz de operar en múltiples sistemas operativos, una característica que sugiere un nivel de sofisticación propio de actores de amenazas bien financiados. De hecho, el equipo de seguridad de Google ha sugerido que el ataque podría tener origen en Corea del Norte, dado el historial de grupos como TraderTraitor en ataques a cadenas de suministro orientados al robo de criptomonedas.
El impacto: cuando el 3% es demasiado
Axios está presente en aproximadamente el 80% de los entornos en la nube, según datos de Orca Security. Aunque «solo» un 3% de los entornos afectados llegaron a ejecutar las versiones comprometidas, en el mundo del software moderno, ese 3% representa potencialmente millones de sistemas. Si consideramos que Axios tiene más de 100 millones de descargas semanales en npm, incluso un porcentaje pequeño se traduce en un número enorme de instalaciones potencialmente afectadas.
¿Nos suena de algo?
Si leyeron nuestro artículo anterior sobre CVE-2026-0848 y el ataque a librerías de Python, este patrón les resultará escalofriantemente familiar. Al igual que en el incidente de XZ Utils, estamos viendo actores de amenazas que invierten tiempo y recursos en comprometer proyectos de código abierto ampliamente utilizados, aprovechando la confianza inherente que depositamos en estas herramientas fundamentales.
La diferencia esta vez es que el ataque fue detectado relativamente rápido gracias a la vigilancia activa de la comunidad de seguridad, pero nos deja una pregunta incómoda: ¿cuántos paquetes npm comprometidos permanecen sin detectar en este momento?
¿Qué debemos hacer ahora?
Si tú o tu organización usaron Axios entre el 30 y 31 de marzo de 2026, estas son las acciones inmediatas que deberían tomar:
1. Auditar archivos package.json y package-lock.json: Busquen referencias a las versiones 1.14.1 o 0.30.4 de Axios, y a plain-crypto-js v4.2.1. Si las encuentran, asuman lo peor.
2. Asumir compromiso total: Cualquier host que haya ejecutado npm install con las versiones comprometidas debe considerarse totalmente comprometido. El RAT tenía capacidades de reconocimiento y exfiltración de datos.
3. Rotar credenciales: Cambien todos los secretos, claves API, tokens de acceso y credenciales que pudieran haber estado expuestos en los sistemas afectados.
4. Reinstalar desde cero: Dado que el malware lograba persistencia en Windows, la única forma segura de remediar un sistema comprometido es una reinstalación limpia.
5. Actualizar a versiones seguras: Las versiones seguras de Axios ya están disponibles en npm. Asegúrense de especificar versiones fijas en sus archivos package.json y considerar el uso de lockfiles para evitar actualizaciones automáticas no deseadas.
Lecciones aprendidas (otra vez)
Este incidente nos deja varias enseñanzas dolorosas. Primero, la autenticación de dos factores, aunque Jason Saayman afirmó que la tenía activada, no fue suficiente para prevenir el compromiso de su cuenta. Segundo, los scripts postinstall siguen siendo un vector de ataque extremadamente efectivo que el ecosistema npm aún no ha resuelto adecuadamente. Tercero, la velocidad de detección y respuesta en este caso fue ejemplar, pero tres horas fueron suficientes para que cientos de sistemas fueran comprometidos.
La realidad es que la cadena de suministro de software seguirá siendo un objetivo atractivo para los atacantes mientras sigamos confiando ciegamente en paquetes de terceros. Tal vez sea momento de considerar herramientas como npm audit, Snyk o soluciones de Software Composition Analysis (SCA) como parte integral de nuestros flujos de desarrollo, no solo como una ocurrencia tardía.
Y recuerden: en el mundo del desarrollo moderno, la confianza no se da, se verifica. Cada dependencia que agregamos a nuestro proyecto es una invitación a código ajeno en nuestros sistemas. Tratemos esas invitaciones con el cuidado que merecen.
Referencias
• El Mundo – «Un ataque compromete a Axios, uno de los paquetes más populares del ecosistema JavaScript»: https://www.elmundo.es/tecnologia/2026/03/31/69cc2dc4e9cf4aeb2f8b4592.html
• StepSecurity – «axios Compromised on npm – Malicious Versions Drop Remote Access Trojan»: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
• Elastic Security Labs – «Inside the Axios supply chain compromise – one RAT to rule them all»: https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all
• LiberumCode – «CVE-2026-0848: Cuando tu librería favorita de Python se convierte en un problema»: https://liberumcode.org/cve-2026-0848-cuando-tu-libreria-favorita-de-python-se-convierte-en-un-problema-y-que-tiene-que-ver-con-el-desastre-de-xz-utils/
• GitHub Issue #10604 – axios@1.14.1 and axios@0.30.4 are compromised: https://github.com/axios/axios/issues/10604
Deja una respuesta