Los piratas informáticos comprometieron el paquete oficial jscrambler npm y publicaron versiones maliciosas que implementaban malware de robo de credenciales en sistemas Windows, Linux y macOS.
El ataque a la cadena de suministro puso en riesgo las estaciones de trabajo de los desarrolladores, los servidores de compilación y los entornos de integración continua. El paquete normalmente recibe alrededor de 15.800 descargas semanales, aunque esa cifra no muestra cuántos usuarios instalaron las versiones maliciosas.
Jscrambler dijo que npm registró 1.479 descargas en las versiones afectadas y paquetes relacionados durante el incidente. La compañía ha desaprobado las versiones comprometidas y recomienda actualizar a la versión 8.22.0 o posterior.
¿Qué versiones de Jscrambler se vieron comprometidas?
La primera versión maliciosa conocida, jscrambler 8.14.0, apareció en npm el 11 de julio de 2026.Equipo de investigación de enchufeslo detectó seis minutos después de su publicación.
Posteriormente, los atacantes publicaron cuatro versiones más comprometidas en aproximadamente tres horas. Cambiaron el método de ejecución del malware durante la campaña, aparentemente para evitar controles de seguridad centrados en los scripts de instalación de npm.
Según el funcionarioAviso de seguridad de Jscrambler, las versiones afectadas han quedado obsoletas y ya no están disponibles a través de la resolución de dependencia normal de npm.
| Paquete | Versiones afectadas | Versión segura |
|---|---|---|
| jscrambler | 8.14.0, 8.16.0, 8.17.0, 8.18.0 y 8.20.0 | 8.22.0 o posterior |
| complemento-jscrambler-webpack | 8.6.2 | 8.6.3 o posterior |
| trago-jscrambler | 8.6.2 | 8.6.3 o posterior |
| gruñido-jscrambler | 8.5.2 | 8.5.3 o posterior |
| complemento-jscrambler-metro | 9.0.2 | 9.0.3 o posterior |
El malware se ejecutó inicialmente durante la instalación de npm
Las versiones 8.14.0, 8.16.0 y 8.17.0 agregaron un comando de preinstalación no documentado que iniciaba un archivo llamado dist/setup.js. Este comando se ejecutó automáticamente cuando un desarrollador instaló el paquete.
Las víctimas no necesitaban importar jscrambler, ejecutar su herramienta de línea de comandos ni agregarlo a una aplicación. Ejecutar npm install con una de las versiones afectadas podría iniciar el malware inmediatamente.
El cargador leyó un segundo archivo llamado dist/intro.js. A pesar de su extensión JavaScript, este archivo era un contenedor binario que contenía tres ejecutables nativos comprimidos.
- El script de preinstalación de npm lanzó dist/setup.js.
- El cargador identificó el sistema operativo de la víctima.
- Seleccionó la carga útil nativa coincidente de dist/intro.js.
- La carga útil se escribió en un archivo temporal oculto con nombre aleatorio.
- El cargador marcó el archivo como ejecutable cuando fue necesario.
- Lanzó el malware de forma silenciosa como un proceso en segundo plano independiente.
Las versiones posteriores eliminaron el gancho de preinstalación.
Los atacantes cambiaron de táctica con las versiones 8.18.0 y 8.20.0. Estas versiones eliminaron el gancho visible del ciclo de vida de npm y colocaron el cargador directamente dentro de los archivos JavaScript principales del paquete.
Luego, el malware se ejecutaba cuando una aplicación importaba jscrambler o cuando un usuario ejecutaba su interfaz de línea de comandos. Este método podría eludir las herramientas que inspeccionaban únicamente los scripts previos y posteriores a la instalación.
También significó que el uso de npm install con la opción –ignore-scripts no previno completamente la infección de versiones maliciosas posteriores.
Las versiones 8.18.0 y 8.20.0 también declararon jscrambler 8.17.0 como dependencia. Este comportamiento podría llevar una versión comprometida a un entorno a través de una dependencia transitiva.
El malware multiplataforma apunta a los secretos de los desarrolladores
El paquete malicioso incluía cargas útiles basadas en Rust para Linux x86-64, Windows x86-64 y Apple Silicon Macs. El cargador no incluía una carga útil nativa para sistemas macOS basados en Intel.
Los investigadores describieron el malware como un ladrón de información extenso diseñado para entornos de desarrolladores y operadores de nube. Sus objetivos incluían datos del navegador, carteras de criptomonedas, aplicaciones de mensajería, credenciales de nube y llaveros de sistemas operativos.
El malware cifró alrededor de 2400 cadenas de configuración confidenciales con ChaCha20-Poly1305. Esta técnica dificultó la inspección estática y ocultó los servicios, las rutas de los archivos y las credenciales a las que intentaba acceder.
- Contraseñas del navegador, cookies e información de sesión
- Carteras de criptomonedas y posibles frases de recuperación
- Datos de sesión de Discord, Slack, Telegram y Steam
- Información sobre el conjunto de claves del sistema operativo y Bitwarden
- Credenciales de git y npm
- Tokens de acceso a la nube y archivos de configuración
- Kubernetes y credenciales de implementación
- Variables de entorno del desarrollador
El ladrón buscó archivos de configuración pertenecientes a varias herramientas de desarrollo asistidas por IA. Estos archivos pueden contener claves API, credenciales de servicio, detalles del servidor local y conexiones del protocolo de contexto modelo.
Objetivos identificados en elAnálisis técnico del zócalo.incluía Claude Desktop, Cursor, Windsurf, Zed, VS Code, VS Code Insiders, Factory y opencode.
El malware también buscó la configuración del servidor MCP. Los desarrolladores suelen utilizar estas configuraciones para conectar herramientas de inteligencia artificial con bases de datos, servicios en la nube, repositorios de origen, aplicaciones internas y otros sistemas privilegiados.
| Categoría objetivo | Ejemplos encontrados en el malware. |
|---|---|
| Herramientas de desarrollo de IA | Claude Desktop, Cursor, Windsurf, Factory, Zed y código abierto |
| editores de código | VS Code y expertos en VS Code |
| Integraciones de IA | Archivos de configuración y credenciales del servidor MCP |
| Plataformas en la nube | Servicios web de Amazon, Google Cloud y Microsoft Azure |
| Sistemas de implementación | Kubernetes, entornos de CI y archivos de configuración local |
Las credenciales de AWS, Azure y Google Cloud estaban en riesgo
La carga útil contenía referencias a ubicaciones de credenciales y servicios de metadatos para las tres principales plataformas en la nube. Estos incluían puntos finales de metadatos de contenedores de AWS, datos de cuentas de servicio de Google Cloud y el servicio de metadatos de Azure Instance.
También buscó bases de datos de credenciales de Google Cloud, credenciales predeterminadas de aplicaciones, datos de AWS Secrets Manager, parámetros de AWS Systems Manager y acceso de administración de Azure.
Una infección exitosa en un servidor de compilación podría exponer a mucho más de una cuenta de desarrollador. Los sistemas de CI suelen contener código fuente, tokens de publicación de paquetes, claves de firma, credenciales de implementación y secretos utilizados para acceder a los servicios de producción.
Los atacantes podrían utilizar tokens robados para acceder a la infraestructura de la nube, modificar versiones de software, comprometer paquetes adicionales o ingresar a entornos de desarrollo conectados.
Jscrambler dice que se abusó de una credencial de publicación de npm
Jscrambler dijo que su investigación encontró que el atacante publicó los lanzamientos maliciosos con una credencial de publicación npm. La empresa no ha explicado públicamente cómo se obtuvo la credencial.
La empresa revocó y rotó sus credenciales de publicación, contraseñas y secretos relacionados. También introdujo controles adicionales en torno a su proceso de publicación de paquetes y comenzó una investigación forense.
El incidente afectó al paquete jscrambler utilizado con el producto Code Integrity de la empresa. Jscrambler dijo que sus otros productos, incluido Webpage Integrity, no se vieron afectados.
El actualizadoasesoría de empresaenumera las versiones de paquetes maliciosos, los paquetes dependientes afectados, las versiones seguras y la guía de solución actual.
Qué deberían hacer ahora los desarrolladores afectados
Las organizaciones deben verificar los archivos de bloqueo de paquetes, los registros de instalación de npm, los registros de compilación y los historiales de CI para detectar las versiones comprometidas. No deben asumir que eliminar la dependencia elimina el riesgo.
Cualquier sistema que haya instalado o ejecutado una versión afectada debe tratarse como potencialmente comprometido. Los equipos de seguridad deben aislar el dispositivo, investigar procesos sospechosos y rotar todas las credenciales a las que pueda acceder el malware.
Los equipos también deben revisar los repositorios y crear resultados creados durante el período de exposición. Un entorno de compilación comprometido puede permitir a los atacantes robar secretos o alterar el software antes de su lanzamiento.
- Actualice jscrambler a la versión 8.22.0 o posterior.
- Actualice los cuatro complementos de Jscrambler afectados a sus versiones seguras enumeradas.
- Busque archivos de bloqueo para las cinco versiones maliciosas de jscrambler.
- Revise los registros de CI y npm para la ejecución de dist/setup.js.
- Investigue ejecutables ocultos lanzados desde directorios temporales.
- Gire las credenciales de npm, GitHub, Git, nube y de implementación.
- Revocar sesiones de navegador, mensajería, administrador de contraseñas y herramientas de desarrollador.
- Reemplace las claves API del servicio AI y del servidor MCP almacenadas en los sistemas afectados.
- Aleje los activos de criptomonedas de las billeteras a las que puede acceder un dispositivo infectado.
- Reconstruya sistemas confidenciales a partir de una imagen confiable cuando los investigadores no puedan confirmar una limpieza completa.
Preguntas frecuentes
¿Qué versiones de jscrambler se vieron comprometidas?
Las versiones comprometidas fueron 8.14.0, 8.16.0, 8.17.0, 8.18.0 y 8.20.0. Jscrambler recomienda actualizar a la versión 8.22.0 o posterior.
¿Cómo ejecutó el malware el paquete malicioso jscrambler?
Las primeras versiones utilizaban un gancho de preinstalación de npm que se ejecutaba durante la instalación. Las versiones posteriores colocaron el cargador dentro del código del paquete, lo que provocó que se ejecutara cuando los desarrolladores importaban el paquete o usaban su herramienta de línea de comandos.
¿A qué información se dirigió el malware jscrambler?
El malware se centró en sesiones de navegador, carteras de criptomonedas, cuentas de mensajería, credenciales de nube, llaveros de sistemas operativos, secretos de desarrolladores, configuraciones de herramientas de codificación de IA y configuraciones de servidores MCP.
¿Cuántas personas descargaron las versiones maliciosas de jscrambler?
Jscrambler dijo que npm registró 1.479 descargas en las versiones afectadas y paquetes dependientes. La cifra de descargas semanales normales del paquete de aproximadamente 15.800 no representa infecciones confirmadas.
¿Qué deben hacer los desarrolladores después de instalar una versión afectada?
Deben aislar e inspeccionar el sistema, actualizarlo a una versión segura y rotar todas las credenciales accesibles. Esto incluye npm, GitHub, nube, implementación, navegador, mensajería, criptomonedas, herramienta de inteligencia artificial y credenciales de MCP.