El paquete jscrambler, con cerca de 15.800 descargas semanales en npm, fue comprometido el 11 de julio de 2026 con una versión maliciosa (la 8.14.0) que ejecuta un hook preinstall capaz de descargar y correr un binario nativo distinto para Windows, macOS y Linux apenas se corre npm install, sin que el desarrollador importe el paquete ni ejecute su CLI. La firma de seguridad de cadena de suministro Socket detectó el artefacto malicioso seis minutos después de su publicación.
Qué pasó
Alguien publicó la release 8.14.0 de jscrambler usando una credencial de publicación comprometida, saltándose el proceso normal de release del proyecto. Esa versión, y otras cuatro que siguieron en las horas posteriores (8.16.0, 8.17.0, 8.18.0 y 8.20.0), quedaron marcadas como comprometidas; la 8.15.0 fue una release limpia intermedia.
Según Socket, el atacante publicó cuatro versiones adicionales en un lapso de aproximadamente tres horas después del primer release malicioso, ajustando el método de ataque sobre la marcha. Los mantenedores de jscrambler retomaron el control y publicaron la versión 8.22.0, confirmada como limpia.
Cómo funciona el ataque vía preinstall
Las primeras versiones comprometidas agregan un hook preinstall no documentado que invoca dist/setup.js. Ese script «descarga y ejecuta en silencio un binario nativo en segundo plano, adaptado al sistema operativo de la víctima», según el análisis de Socket, sin que haga falta importar el paquete ni correr el CLI de Jscrambler. El payload es un infostealer escrito en Rust, con binarios separados para Linux (x86-64), Windows (x86-64) y macOS (ARM64), que en Linux llega a cargar código eBPF en el kernel. El objetivo son credenciales de nube (AWS, GCP, Azure), billeteras de criptomonedas (MetaMask, Phantom, Exodus, Trust Wallet), gestores de contraseñas y datos de navegador, configuraciones de asistentes de IA (Claude, Cursor, Windsurf, VS Code, Zed) y tokens de sesión de Discord, Slack, Telegram y Steam.
En las versiones posteriores (8.18.0 y 8.20.0), el atacante movió el dropper del hook preinstall hacia el código principal del paquete, de modo que instalar con la bandera --ignore-scripts (la defensa estándar contra este tipo de ataque) deja de ser suficiente para evitarlo.
Qué hacer si instalaste esa versión
Si tu lockfile referencia jscrambler 8.14.0, 8.16.0, 8.17.0, 8.18.0 u 8.20.0, la recomendación es actualizar de inmediato a la versión 8.22.0 (o pinear a la 8.13.0, la última confirmada limpia antes del incidente), y limpiar cualquier copia en caché de npm de las versiones afectadas.
Si alguna de esas versiones llegó a instalarse en una máquina de desarrollo o en un pipeline de CI/CD, hay que asumir que el binario se ejecutó y rotar credenciales: claves de nube, tokens de npm y de GitHub, API keys de herramientas de IA, y revisar sesiones de navegador y accesos a billeteras de criptomonedas. También conviene auditar logs de instalación en busca de la ejecución de dist/setup.js y bloquear las direcciones de comando y control identificadas por Socket (37.27.122[.]124 y 57.128.246[.]79, además de infraestructura Tor asociada).
Una alerta más para los pipelines de la comunidad
Para equipos que corren npm install en CI/CD sin revisar cada dependencia transitiva, este incidente confirma algo que viene repitiéndose en el ecosistema npm: un solo hook de instalación puede ejecutar código arbitrario antes de que corra una sola línea de la aplicación. Bloquear scripts de instalación por defecto, fijar versiones exactas en el lockfile y monitorear cambios inusuales en paquetes de uso frecuente son medidas concretas y de bajo costo.
¿Tu pipeline de CI/CD corre con --ignore-scripts por defecto, o instala dependencias confiando en que npm y el mantenedor del paquete hicieron bien su trabajo?
Fuentes
- The Hacker News — Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install
- Socket — jscrambler npm Package Compromised in Supply Chain Attack
