Un incidente de software supply chain ha afectado al popular paquete Axios en npm, una librería ampliamente usada en proyectos Node.js para realizar peticiones HTTP. Según la investigación publicada, atacantes lograron publicar dos versiones maliciosas de Axios —axios@1.14.1 y axios@0.30.4— que estuvieron disponibles durante aproximadamente unas tres horas. Aunque el cambio parecía pequeño de cara al usuario, el impacto potencial es alto porque puede afectar tanto a máquinas de desarrolladores como, sobre todo, a pipelines de CI/CD y runners de build que instalan dependencias automáticamente.

Lo más relevante es que el código principal de Axios no habría sido modificado directamente. En su lugar, los atacantes introdujeron una nueva dependencia en el package.json: plain-crypto-js@^4.2.1. Esa dependencia maliciosa aprovechaba un mecanismo común en el ecosistema npm: los scripts de instalación, en este caso un post-install, que se ejecuta al instalar el paquete. A partir de ahí, se lanzaba un dropper ofuscado (mencionado como setup.js) que contactaba con una infraestructura de C2 (command and control) para descargar cargas útiles distintas en función del sistema operativo.

La cadena de infección descrita apunta a un comportamiento claramente orientado a maximizar la compatibilidad y el alcance. En Windows, se emplean técnicas con VBScript y PowerShell, incluyendo persistencia y la copia de un binario/artefacto con nombre wt.exe en la ruta %PROGRAMDATA%\wt.exe. En macOS, la ejecución se apoya en AppleScript para descargar y lanzar un binario en /Library/Caches/com.apple.act.mond. En Linux, se cita un payload en Python escrito en /tmp/ld.py y ejecutado de forma desacoplada con nohup, lo que puede dificultar la detección a simple vista en entornos automatizados.

La carga final se describe como un RAT (Remote Access Trojan) con capacidades típicas de control remoto: ejecutar comandos, enumerar directorios, mantener persistencia y descargar/ejecutar binarios codificados en base64. Además, el dropper intenta complicar el análisis forense borrándose a sí mismo y restaurando un package.json ‘limpio’ tras la infección, un detalle que puede hacer que una revisión superficial del repositorio o del árbol de dependencias no detecte fácilmente el origen.

Para organizaciones que dependan de Axios en producción, el riesgo principal no es solo el puesto del desarrollador, sino el entorno de construcción: si un runner instaló una de las versiones afectadas, el atacante podría haber obtenido una vía para robar secretos (por ejemplo, tokens de despliegue) o ejecutar acciones en el contexto del pipeline. Por ello, se recomienda bloquear explícitamente axios@1.14.1 y axios@0.30.4, fijar versiones a axios@1.14.0 o axios@0.30.3 (según la rama utilizada), y auditar lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) y logs de instalación para confirmar si se resolvió la dependencia plain-crypto-js durante la ventana de exposición.

Si hay indicios de instalación o ejecución, las medidas prudentes pasan por rotar credenciales (incluyendo secrets de CI, claves SSH y tokens API), revisar artefactos y hosts en busca de los indicadores citados (%PROGRAMDATA%\wt.exe, /Library/Caches/com.apple.act.mond, /tmp/ld.py) y, cuando corresponda, reconstruir entornos desde un estado conocido bueno. Como aprendizaje estructural, el caso refuerza la necesidad de controles de procedencia en publicaciones (por ejemplo, provenance/OIDC), alertas ante releases sin correlación con commits en GitHub, y restricciones/monitorización de scripts post-install en dependencias.

Más información

• BleepingComputer: https://www.bleepingcomputer.com/news/security/hackers-compromise-axios-npm-package-to-drop-cross-platform-malware/