Estos días se ha hecho público uno de los incidentes de supply chain más serios que hemos visto en el ecosistema JavaScript: el compromiso de Axios, una de las librerías HTTP más utilizadas en JavaScript, con más de 300 millones de descargas semanales.

El incidente no ha sido un fallo de código, sino algo más preocupante: han secuestrado la cuenta del mantenedor principal en npm y, con ella, el canal legítimo por el que se publican nuevas versiones.

¿Qué ha pasado exactamente?

Según el análisis publicado por Aikido y otros investigadores:

• El atacante compromete la cuenta npm del mantenedor (jasonsaayman) y publica durante la madrugada del 31 de marzo dos versiones maliciosas: [email protected] y [email protected].
• Estas versiones no tienen commits ni tags correspondientes en GitHub: se publican directamente en npm con un token robado, fuera del flujo normal de CI.
• La única diferencia en el código es la inclusión de una nueva dependencia, [email protected], que no se usa en el código de axios, pero se ejecuta durante la fase de postinstall.
• Ese postinstall, la cual se autoejecuta al hacer la instalación con npm/pnpm, descarga y despliega un RAT (Remote Access Trojan), con payloads específicos para macOS, Windows y Linux.
• Tras ejecutarse, el malware se “elimina” a sí mismo de node_modules y deja un paquete limpio, lo que lo oculta al inspeccionar la carpeta después de la instalación. La clave para la detección está en revisar el lockfile y las versiones instaladas.

Por el impacto de axios en el ecosistema, estamos ante uno de los ataques de cadena de suministro más relevantes en npm hasta la fecha.

Qué deben hacer las organizaciones que usan Axios

Aunque npm ya ha retirado las versiones maliciosas, cualquier equipo que haya podido instalar 1.14.1 o 0.30.4 entre las 00:00h y 06:00h (horas aproximadas en formato UTC) debe asumir el compromiso en la máquina o pipeline donde se realizó la instalación. Este compromiso implica la posibilidad de la exfiltración de datos sensibles, especialmente credenciales almacenadas en código o variables de entorno.

Las recomendaciones técnicas de alto nivel son:

• Revisar los ficheros package-lock.json/pnpm-lock.yaml/yarn.lock  en el código fuente para detectar la presencia de [email protected], [email protected] o [email protected].
• Si se han instalado, buscar los artefactos del RAT en los sistemas (en particular archivos como /Library/Caches/com.apple.act.mond en macOS, %PROGRAMDATA%\wt.exe en Windows o /tmp/ld.py en Linux).
• En caso de encontrar indicios, no limpiar “a mano” en las propias máquinas, si no que se debe reconstruir desde una imagen conocida, revisar logs de CI/CD y rotar todas las credenciales a las que pudiera haber accedido ese nodo (tokens npm, claves o tokens de cloud, secretos de pipeline, etc.).
• Fijar versiones seguras ([email protected] / 0.30.3) y añadir overrides o resolutions para evitar que dependencias transitivas resuelvan a versiones no deseadas.

Lecciones para cualquier equipo de desarrollo

Más allá del caso particular, este incidente vuelve a dejarnos varias lecciones clave:

• La confianza está en la cadena, no solo en el código
  No basta con “confiar” en una librería popular. Si el canal de publicación (la cuenta del mantenedor o el pipeline) se ve comprometido, toda la comunidad hereda el riesgo.
• La velocidad de actualización tiene que ir acompañada de controles
  Adoptar automáticamente la última versión de todo es muy cómodo… hasta que una actualización introduce malware. Establecer políticas como edad mínima de paquete o revisiones manuales para ciertas dependencias críticas es una medida muy razonable.
• CI/CD es un activo crítico de seguridad
  Si un atacante logra desplegar un RAT desde una simple instalación de dependencias, lo siguiente que va a mirar son los secretos del pipeline y el acceso a otros entornos. La seguridad de la cadena de suministro de software, y especialmente el CI/CD, debe tratarse como la de un entorno productivo.
• La detección manual no es suficiente
  En este ataque, el malware se borraba tras su ejecución, dejando un node_modules aparentemente “limpio”. La única forma fiable de detectar el problema era combinar información de versiones, lockfiles e IOCs de sistema.

Buenas prácticas que recomendamos

A raíz de este caso, nuestras recomendaciones mínimas para equipos que desarrollan con npm/yarn/pnpm son:

• Usar lockfiles y comandos como npm ci para instalaciones reproducibles.
• Limitar y monitorizar quién puede publicar versiones de paquetes internos, y cómo (idealmente siempre desde CI con identidades vinculadas).
• Introducir controles automatizados para detectar dependencias nuevas o versiones recién publicadas antes de que entren en producción.​
• Tratar los nodos de build y CI como sistemas de alta sensibilidad, con segmentación, monitorización y rotación sistemática de secretos.
• Crear un catálogo automatizado de librerías instaladas en el software, haciendo uso de estándares como el Software Bill of Materials (SBOM), permite trazar estos fallos de seguridad de forma muy rápida, y ágil ante nuevas alertas.

Si quieres reforzar la seguridad de tu cadena de suministro de software y prevenir incidentes como este, contacta con nosotros en Ciberso: te ayudaremos a detectar riesgos, anticiparte a amenazas y poner en marcha medidas eficaces para proteger tu entorno.