jscrambler del registro npm fue comprometido el 11 de julio de 2026 mediante una credencial de publicación robada y utilizado para distribuir silenciosamente un infostealer desarrollado en Rust contra sistemas Windows, macOS y Linux. Los investigadores identificaron cinco versiones maliciosas publicadas durante aproximadamente tres horas, con capacidad para robar credenciales, sesiones del navegador y otros datos sensibles de estaciones de trabajo de desarrolladores y entornos de integración continua.
Un ataque a la cadena de suministro compromete el paquete npm de Jscrambler
El ecosistema npm registró el 11 de julio de 2026 un nuevo ataque contra la cadena de suministro de software después de que el paquete oficial jscrambler, utilizado para integrar las herramientas de protección de código JavaScript de Jscrambler en procesos de desarrollo y compilación, fuera manipulado para distribuir malware multiplataforma.
La primera versión maliciosa detectada fue la 8.14.0, publicada ese mismo día. Incorporaba un hook de preinstall no documentado que se ejecutaba automáticamente durante la instalación del paquete mediante npm y desplegaba un ejecutable nativo adaptado al sistema operativo de la víctima. El código podía seleccionar una carga específica para Windows, macOS o Linux.
Socket informó de que detectó la versión comprometida apenas seis minutos después de su publicación. Según sus datos, el paquete registraba alrededor de 15.800 descargas semanales, aunque no existe por ahora una cifra confirmada de sistemas realmente infectados. Por ello, no puede afirmarse que todos sus usuarios o descargas hayan resultado comprometidos.
Cinco versiones maliciosas fueron publicadas en unas tres horas
El incidente evolucionó rápidamente. Las investigaciones posteriores determinaron que el ataque no se limitó a jscrambler@8.14.0. Durante aproximadamente tres horas fueron publicadas al menos cinco versiones que contenían la misma carga maliciosa: 8.14.0, 8.16.0, 8.17.0, 8.18.0 y 8.20.0.
SafeDep reconstruyó una sucesión de publicaciones en la que versiones maliciosas se alternaron con versiones aparentemente limpias. La 8.14.0 apareció a las 15:12 UTC; la 8.15.0, considerada limpia, fue publicada a las 17:07 UTC; y solo 19 minutos después apareció la 8.16.0 con el mismo malware. Posteriormente llegaron las versiones comprometidas 8.17.0, 8.18.0 y 8.20.0.
Este comportamiento sugiere que, durante parte del incidente, los responsables legítimos y el atacante mantuvieron una disputa activa por el control del canal de publicación. Jscrambler confirmó posteriormente que los paquetes fueron publicados utilizando una credencial npm comprometida, mientras su investigación forense continuaba abierta.
Cómo funcionaba el infostealer distribuido a través de npm
En las primeras versiones afectadas —8.14.0, 8.16.0 y 8.17.0—, el ataque utilizaba un script preinstall que ejecutaba dist/setup.js. Este archivo leía un contenedor binario de aproximadamente 7,8 MB oculto bajo el nombre dist/intro.js, seleccionaba el ejecutable correspondiente al sistema operativo, lo descomprimía en un directorio temporal con un nombre aleatorio y lo ejecutaba de forma separada del proceso de instalación de npm.
La situación cambió en las versiones 8.18.0 y 8.20.0. El atacante eliminó el mecanismo de preinstall e inyectó directamente el dropper en el código principal del paquete y en su herramienta de línea de comandos. De este modo, el malware podía activarse cuando una aplicación importaba jscrambler o ejecutaba su CLI, incluso en determinados escenarios donde se utilizara npm install --ignore-scripts.
Esta modificación amplió la superficie de riesgo, porque una revisión centrada exclusivamente en detectar scripts automáticos de instalación podía no identificar las últimas variantes maliciosas.
Qué información podía robar el malware
Los análisis técnicos describen la carga como un infostealer multiplataforma compilado en Rust. Entre sus objetivos se encontraban datos almacenados en perfiles de navegadores basados en Chromium, incluidos Chrome, Brave, Edge y Chromium, además de información de la extensión de Bitwarden y sesiones de Steam.
Otros análisis del incidente también señalaron el posible acceso a credenciales de servicios en la nube, tokens utilizados en entornos de desarrollo y CI/CD, sesiones autenticadas y secretos almacenados en equipos de desarrolladores. El alcance concreto dependía de los datos disponibles en cada sistema infectado y de los privilegios del proceso ejecutado.
En Windows, el malware podía establecer persistencia mediante tareas programadas ocultas. En macOS, utilizaba archivos LaunchAgent capaces de volver a ejecutar la carga después de reinicios. Los investigadores también identificaron ejecutables nativos específicos para Linux.
Por qué los desarrolladores y los pipelines de CI/CD estaban especialmente expuestos
El paquete jscrambler se utiliza como herramienta de desarrollo y puede integrarse en procesos automatizados para proteger código JavaScript antes de su despliegue. Por ello, una versión comprometida tenía potencial para ejecutarse tanto en estaciones de trabajo de desarrolladores como en servidores y runners empleados para tareas de integración y entrega continua.
Este tipo de entornos resulta particularmente sensible porque puede contener tokens de GitHub, credenciales npm, claves SSH, secretos de servicios en la nube, variables de entorno y otros mecanismos de autenticación utilizados para acceder a repositorios, desplegar aplicaciones o publicar nuevos paquetes.
No obstante, hasta el momento no se ha confirmado públicamente que el malware consiguiera comprometer miles de estaciones de trabajo o pipelines concretos. La popularidad del paquete evidencia una superficie potencial significativa, pero las cifras reales de infecciones continúan sin estar determinadas. Jscrambler indicó inicialmente que npm mostraba cero descargas de las versiones maliciosas, aunque advirtió de que esos datos podían sufrir retrasos y seguían bajo verificación.
La versión maliciosa no aparecía en el repositorio oficial de GitHub
Uno de los principales indicios del compromiso fue la diferencia entre lo publicado en npm y el código disponible en el repositorio público del proyecto.
Los investigadores comprobaron que las versiones maliciosas no tenían un commit, una etiqueta o una publicación equivalente en el repositorio oficial de GitHub. La última versión limpia anterior al ataque, la 8.13.0, sí coincidía con el historial público del proyecto, mientras que la 8.14.0 apareció directamente en npm con nuevos archivos y mecanismos de ejecución inexistentes en el código fuente público.
Este hallazgo apuntó inicialmente hacia el compromiso de una cuenta npm o del proceso de publicación, hipótesis confirmada posteriormente cuando Jscrambler comunicó que el atacante había utilizado una credencial npm comprometida.
La versión 8.22.0 fue identificada como limpia
Después de varias publicaciones maliciosas y de los intentos de corrección realizados durante el incidente, los análisis de Socket, StepSecurity y SafeDep identificaron la versión 8.22.0 como una publicación limpia y recomendaron migrar a ella o a otra versión previamente verificada.
Las versiones comprometidas identificadas son:
8.14.0, 8.16.0, 8.17.0, 8.18.0 y 8.20.0.
La investigación de SafeDep indicó además que las versiones 8.14.0, 8.16.0 y 8.17.0 habían sido marcadas como comprometidas, mientras que, en el momento de su último análisis, las versiones 8.18.0 y 8.20.0 continuaban publicadas sin esa indicación.
Qué deben hacer quienes instalaron una versión comprometida
Los investigadores recomiendan considerar potencialmente comprometido cualquier sistema en el que se haya instalado o ejecutado alguna de las cinco versiones maliciosas.
La respuesta no debería limitarse a desinstalar el paquete. Las recomendaciones incluyen actualizar a la versión 8.22.0 o a otra publicación verificada, revisar archivos de bloqueo y cachés, auditar registros de instalaciones y ejecuciones, analizar los sistemas afectados y rotar las credenciales potencialmente accesibles desde esas máquinas.
Entre los secretos que pueden requerir rotación figuran credenciales de servicios en la nube, tokens de npm y GitHub, claves utilizadas por herramientas de inteligencia artificial y protocolos MCP, sesiones de navegador y otros datos de autenticación presentes en el equipo. Los investigadores también aconsejan examinar posibles mecanismos de persistencia en el Programador de tareas de Windows y en ~/Library/LaunchAgents de macOS.
El ataque vuelve a situar el foco sobre la seguridad de la cadena de suministro
El compromiso de jscrambler representa otro ejemplo de cómo una credencial de publicación robada puede convertir un paquete legítimo en un mecanismo de distribución de malware.
En este caso, el código malicioso no necesitaba explotar una vulnerabilidad de la aplicación final. Bastaba con que una versión afectada fuera instalada o, en determinadas variantes posteriores, importada o ejecutada, para activar la carga correspondiente al sistema operativo.
El incidente también evidencia la importancia de comparar los paquetes distribuidos en registros públicos con sus repositorios de código fuente, controlar las versiones mediante archivos de bloqueo, proteger las credenciales de publicación y limitar los secretos disponibles en estaciones de desarrollo y procesos automatizados.
La investigación forense seguía en curso tras el incidente y, aunque se confirmó el uso de una credencial npm comprometida, no se había establecido públicamente la cifra definitiva de equipos infectados ni el alcance total del posible robo de información.
