MagnoSec
Terminal mostrando npm install con alerta de seguridad y código malicioso en Rust siendo descargado desde el paquete jscrambler comprometido

MagnoSec Blog

Paquete jscrambler de npm Comprometido: El Infostealer que Llegó por el Canal Oficial en Solo 6 Minutos

Por Equipo MagnoSec4 min de lectura

jscrambler 8.14.0: 6 minutos que comprometieron cientos de pipelines CI/CD

jscrambler es una herramienta de ofuscación de JavaScript utilizada por empresas de todo el mundo para proteger su código frontend contra ingeniería inversa. Irónicamente, la propia herramienta de protección de código fue el vector de un ataque de supply chain. El 11 de julio de 2026, la cuenta de npm del mantenedor de jscrambler fue comprometida y se publicó la versión 8.14.0 del paquete, que incluía un script preinstall modificado. Este script descargaba y ejecutaba un binario nativo escrito en Rust —un infostealer— que se ejecutaba automáticamente en los sistemas de los desarrolladores al hacer npm install. Socket.dev detectó la versión maliciosa en solo 6 minutos, pero en ese breve lapso, cientos de instalaciones automáticas en pipelines CI/CD ya habían ejecutado el malware en servidores de build con acceso a secretos, tokens y credenciales de producción.

El infostealer en Rust: multiplataforma, sigiloso y difícil de analizar

El infostealer de Rust integrado en jscrambler 8.14.0 estaba diseñado para ser multiplataforma: el mismo código base compilado para Windows, Linux y macOS, garantizando que cualquier desarrollador que instalara el paquete, independientemente de su sistema operativo, ejecutara el malware. Una vez activo, el stealer recopilaba cookies de todos los navegadores instalados, claves SSH del directorio .ssh, tokens de npm y GitHub desde los archivos de configuración, variables de entorno que contuvieran secretos (señal reveladora: buscaba patrones como API_KEY, TOKEN, SECRET, PASSWORD) y archivos .env y .npmrc del sistema de archivos local. Toda la información se empaquetaba y se enviaba a un servidor de comando y control mediante una conexión WebSocket cifrada que se camuflaba como tráfico de telemetría de npm, eludiendo la monitorización de red básica.

Qué roba: cookies, claves SSH, tokens npm/GitHub, .env y secretos de entorno

La elección de Rust como lenguaje para el payload malicioso no es casual. Rust compila a binarios nativos que son más difíciles de analizar estáticamente que los scripts de Node.js habituales en ataques a npm. Un binario de Rust ofuscado no revela sus capacidades en un simple cat del archivo, a diferencia de un script postinstall en JavaScript que cualquier desarrollador puede leer. Además, los binarios de Rust tienen un rendimiento excelente y un footprint mínimo, lo que permite que el stealer opere en segundo plano sin consumir recursos que alerten al desarrollador. Es una evolución táctica en el malware de supply chain: del script interpretado al binario compilado, de la ofuscación simple a la compilación nativa.

CI/CD comprometido: el regalo perfecto para un atacante de supply chain

La ventana de exposición de 6 minutos es engañosamente pequeña. En esos 6 minutos, pipelines de CI/CD que ejecutan npm install o npm update con dependencias no fijadas —algo común en configuraciones de desarrollo y staging— descargaron automáticamente la versión comprometida. El daño no se limita a los desarrolladores que manualmente ejecutaron npm install en ese lapso: cualquier CI/CD configurado para instalar la última versión de las dependencias se vio afectado. Y lo que es peor, el acceso a secretos desde un pipeline de CI/CD comprometido es el regalo perfecto para un atacante: tokens de despliegue de AWS, claves de API de servicios cloud, credenciales de Docker Hub, tokens de GitHub con acceso a repositorios privados. Un pipeline comprometido durante 6 minutos puede exponer credenciales que tardan semanas en rotarse completamente.

Cómo auditamos dependencias y pipelines en MagnoSec

En MagnoSec, las auditorías de código fuente y los ejercicios de seguridad DevSecOps incluyen la cadena de suministro de dependencias como vector de ataque prioritario. Revisamos no solo las dependencias directas de un proyecto, sino también las transitivas, los scripts de instalación, y las configuraciones de CI/CD que determinan qué fuentes de paquetes se consideran confiables. Para mitigar ataques como el de jscrambler, recomendamos fijar las versiones exactas de todas las dependencias con hashes de integridad en lockfiles, utilizar mirrors privados de npm que permitan revisar paquetes antes de distribuirlos internamente, y monitorizar las ejecuciones de scripts postinstall/preinstall en busca de actividad de red inusual. La confianza en npm no puede ser ciega: cada npm install es una puerta que se abre a código de terceros.

Protección: lockfiles con hashes, mirrors privados y monitorización de scripts de instalación

La mitigación inmediata para equipos que utilicen jscrambler es verificar la versión instalada y asegurarse de que no sea la 8.14.0. Si se detecta esa versión, rotar todas las credenciales que hayan estado expuestas en el sistema donde se instaló: tokens de npm, claves SSH, tokens de GitHub, credenciales cloud y cualquier secreto accesible desde la máquina del desarrollador o el pipeline CI/CD. Pero la lección de fondo es más amplia: cualquier paquete npm, independientemente de su popularidad, propósito o reputación del mantenedor, puede ser comprometido en minutos. La defensa no está en confiar en los paquetes: está en verificar lo que entra en tu sistema cada vez que ejecutas npm install.

Temas tratados

jscrambler · npm supply chain · Rust infostealer · paquete comprometido · npm malware · supply chain attack · seguridad npm

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?