Versiones maliciosas de Axios despliegan un troyano de acceso remoto

Versiones maliciosas de Axios (1.14.1 y 0.30.4) despliegan un troyano de acceso remoto mediante un ataque de cadena de suministro

Tiempo estimado de lectura: 5 min

Ideas clave

Dos releases maliciosos: axios@1.14.1 y axios@0.30.4 publicados en npm el 2026-03-31 que introdujeron un RAT via dependencia secundaria.
Dependencia trampa: se añadió plain-crypto-js@4.2.1 con un script postinstall que descarga payloads desde http://sfrclak.com:8000.
Vector operacional: publicación manual con credenciales npm comprometidas; installs que usan latest sin lockfile pueden ejecutar código remoto.
Mitigación observada: detecciones automáticas (por ejemplo, Socket) y bloqueos de plataformas como Vercel ayudaron a contener la propagación.

Tabla de contenidos

Introducción

El 31 de marzo de 2026 se publicaron en npm dos versiones maliciosas de Axios —1.14.1 y 0.30.4— que desplegaban un troyano de acceso remoto a través de una dependencia secundaria. Este incidente demuestra cómo una falla operacional en el ecosistema de paquetes puede convertir una librería ampliamente descargada en un vector de compromisos masivos.

Resumen rápido (lectores con prisa)

Qué: Axios publicó dos releases maliciosos que añadieron plain-crypto-js@4.2.1 con un postinstall que descarga y ejecuta un RAT.

Cuándo: Publicado en npm el 2026-03-31; la dependencia trampa se subió ~18 horas antes.

Por qué importa: installs que resuelven latest sin lockfile pueden ejecutar código remoto inmediatamente al correr npm install.

Cómo funciona: el postinstall contacta a un C2 en http://sfrclak.com:8000 y descarga payloads por plataforma que actúan como RAT.

Qué ocurrió, técnicamente

Acceso y publicaciones

Un atacante obtuvo acceso a las credenciales npm de un mantenedor principal de Axios, cambió el correo de la cuenta y publicó manualmente dos releases fuera del pipeline CI/CD y sin tags en GitHub. Las dos ramas (1.x y 0.x) fueron comprometidas con 39 minutos de diferencia.

Dependencia trampa

Previamente se subió la dependencia trampa plain-crypto-js@4.2.1 aproximadamente 18 horas antes de las releases. Esa dependencia definía un script postinstall que se ejecuta durante npm install y actúa como dropper.

Impacto en installs

Installs que resolvían latest sin un lockfile podían ejecutar código remoto tan pronto como npm install corría. Resultado: posibilidad de ejecución remota de código en entornos locales, CI y servidores de build.

Cómo funciona el malware (anatomía técnica)

1. Vector

No se modificó el código funcional de Axios; se añadió una dependencia maliciosa en el árbol de dependencias.

2. Trigger

plain-crypto-js define un script postinstall. Npm ejecuta por defecto scripts de lifecycle en install, lo que activa la carga maliciosa.

3. Dropper

El postinstall contacta al servidor C2 y descarga un payload específico por plataforma (macOS, Windows, Linux). El servidor observado es http://sfrclak.com:8000.

4. Persistencia y evasión

El payload ejecuta acciones maliciosas, luego se autoelimina y sobrescribe su propio package.json con contenido “limpio” para dificultar auditorías forenses. Si el script se ejecutó en entornos con secretos (CI, máquinas de build, servidores), la exposición es grave.

Diagnóstico rápido: cómo saber si te afectó

Asume compromiso si ejecutaste npm install o instalaciones globales sin lockfile después de 2026-03-31T00:21:58Z. Búsquedas imprescindibles:

Revisar lockfiles y dependencias transitivas: package-lock.json / yarn.lock / pnpm-lock.yaml: busca axios@1.14.1 o axios@0.30.4.
Buscar en node_modules: busca plain-crypto-js.
Logs de red: busca conexiones a http://sfrclak.com:8000 o a sfrclak.com.
Sistemas CI: revisa jobs que corrieron npm install sin --ignore-scripts.

Comandos útiles:

grep -E "axios.*(1\.14\.1|0\.30\.4)" package-lock.json || true
grep -r "plain-crypto-js" node_modules || true
journalctl -u your-ci-agent.service | grep "sfrclak.com" || true

Remediación inmediata (ordenada y práctica)

Fija la versión segura en tus proyectos: axios@1.14.0 o axios@0.30.3 en package.json.

Purge e instala de nuevo desde estado limpio:

npm cache clean --force
rm -rf node_modules
npm install

Rota TODOS los secretos de entornos que pudieron ejecutar el script: tokens CI, claves API, accesos a bases de datos y claves SSH.
Redespliega desde artefactos construidos en entornos sanos.
En CI, añade por defecto:
```
npm ci --ignore-scripts
```
Y autoriza scripts de instalación solamente de forma explícita y revisada.
Audita y notifica: si detectas conexiones a http://sfrclak.com:8000, asume exfiltración y sigue el protocolo de respuesta de incidentes de tu organización.

Medidas arquitectónicas y criterio técnico para evitarlo

Denegar por defecto: CI debe ejecutar --ignore-scripts y solo permitir scripts documentados y revisados.
Lockfiles en control de versiones: no sólo package.json; el lockfile debe revisarse y aprobarse en PR.
Auditoría de transitivas: integra escáneres (por ejemplo, Socket, Snyk, Dependabot) como paso obligatorio en PR y en pipelines.
Política de least privilege para cuentas de publish: MFA obligatorio, rotación de accesos, uso de cuentas de bot con límites.
Aislamiento de builders: construye artefactos en runners frescos y con secreto mínimo; evita que builders tengan credenciales de producción.
Monitorización post-install: alertas en EDR, inspección de conexiones salientes y huellas de procesos anómalos.

Cierre: esto no acaba aquí

Un mantenedor comprometido puede provocar daño a escala en minutos. La conclusión operativa es simple: reduce la superficie de ejecución de scripts, exige lockfiles revisados y trata las dependencias como parte del perímetro de seguridad. Implementa --ignore-scripts en CI, audita transitivas y rota secretos hoy mismo. Mañana publicaremos una checklist técnica para automatizar la autorización de scripts en pipelines y ejemplos de políticas IaC para entornos CI/CD.

Dominicode Labs

Para equipos que automatizan validaciones de seguridad en pipelines y flujos de trabajo, es recomendable integrar pasos automatizados de autorización y escaneo. Para recursos y pruebas aplicadas a pipelines, vea Dominicode Labs como continuación lógica de las medidas técnicas descritas.

FAQ

¿Cómo sé si ejecuté el script malicioso?
¿Qué versiones de Axios son seguras ahora?
¿Debo rotar todos los secretos aunque no detecte conexiones al C2?
¿Por qué no basta con eliminar la dependencia maliciosa?
¿Qué configuraciones de CI deben cambiarse inmediatamente?
¿Dónde puedo ver la página oficial del paquete afectado?

¿Cómo sé si ejecuté el script malicioso?

Asume compromiso si corriste npm install sin lockfile después de 2026-03-31T00:21:58Z. Busca la presencia de plain-crypto-js en node_modules, entradas de axios@1.14.1 o axios@0.30.4 en tus lockfiles y conexiones a http://sfrclak.com:8000 en logs de red.

¿Qué versiones de Axios son seguras ahora?

Fija a axios@1.14.0 o axios@0.30.3 según la rama que uses. No uses las versiones 1.14.1 ni 0.30.4.

¿Debo rotar todos los secretos aunque no detecte conexiones al C2?

Sí. Si un postinstall se ejecutó en un entorno con acceso a secretos, existe riesgo de exposición incluso sin señales evidentes de conexiones; rote tokens CI, claves API y credenciales de acceso como medida cautelar.

¿Por qué no basta con eliminar la dependencia maliciosa?

El payload puede haber ejecutado acciones, creado persistencia o exfiltrado secretos antes de ser removido; además, puede haber sobrescrito artefactos y ocultado rastros. La remediación debe incluir rotación de secretos y reconstrucción desde artefactos sanos.

¿Qué configuraciones de CI deben cambiarse inmediatamente?

Ejecutar por defecto npm ci --ignore-scripts, no almacenar credenciales de producción en runners que ejecutan installs, exigir revisión y aprobación del lockfile en PR y limitar cuentas con permisos de publish mediante MFA y políticas de least privilege.

¿Dónde puedo ver la página oficial del paquete afectado?

La página oficial del paquete Axios en npm está disponible en página del paquete Axios en npm.