La versión comprometida de jscrambler 8.14.0 npm elimina Rust Infostealer durante la instalación – CYBERDEFENSA.MX

El paquete jscrambler npm se vio comprometido y con solo instalar su versión 8.14.0 se ejecuta un robo de información en su máquina. Publicada el 11 de julio de 2026, la versión maliciosa incluye un gancho de preinstalación que coloca y ejecuta un binario nativo, uno para Windows, otro para macOS y otro para Linux.

Socket marcó el lanzamiento seis minutos después de su publicación. Si usted o uno de sus sistemas de compilación lo abrió en esa ventana, la carga útil ya se ejecutó con cualquier acceso que tuviera su proceso de instalación.

Nada de esto está en la versión anterior, 8.13.0. La diferencia del paquete muestra dos archivos nuevos en dist/: setup.js, un pequeño cargador e intro.js. A pesar del nombre, intro.js no es JavaScript sino un contenedor de aproximadamente 7,8 MB que contiene tres archivos binarios nativos comprimidos con gzip, uno para Linux, uno para Windows y otro para macOS.

Durante la instalación, setup.js elige el binario para el sistema operativo host, lo escribe con un nombre aleatorio en el directorio temporal del sistema, lo marca como ejecutable y lo inicia separado con su salida oculta.

Los archivos agregados están en el paquete publicado, pero en ninguna parte de la fuente pública de jscrambler. PasoSeguridad y SafeDep Ambos extrajeron y analizaron la versión, y ambos informan que no hay confirmación, etiqueta o solicitud de extracción coincidentes para 8.14.0 en el repositorio de GitHub.

Su última etiqueta sigue siendo 8.13.0. La versión se envió directamente a npm con una cuenta de mantenimiento legítima, sin pasar por el flujo de lanzamiento normal del proyecto. Eso apunta a una cuenta npm comprometida o una canalización de compilación. Cuál de los dos no ha sido establecido.

La carga útil es un ladrón de información de Rust, creado para las tres plataformas, que busca secretos en una máquina de desarrollador y los envía a un servidor directo a través de TLS, según el análisis actualizado de Socket y una declaración a The Hacker News.

Ciberseguridad

La lista de objetivos es amplia y está dirigida a desarrolladores: credenciales de nube de AWS, Azure y Google Cloud, incluidos los puntos finales de metadatos que utilizan los corredores de CI; billeteras de criptomonedas y frases iniciales de MetaMask, Phantom y Exodus; la bóveda del administrador de contraseñas de Bitwarden; contraseñas y cookies almacenadas en el navegador; y sesiones de Discord, Slack, Telegram y Steam.

También busca algo más nuevo: los archivos de configuración para herramientas de codificación de IA, incluidos Claude Desktop, Cursor, Windsurf, VS Code y Zed, donde tienden a ubicarse las claves API y las credenciales del servidor Model Context Protocol.

Los binarios hacen más que robar. En Linux, la carga útil vincula la biblioteca BPF del kernel y puede cargar un programa eBPF directamente en el kernel desde la memoria. Se trata de un punto de apoyo en el núcleo, no del acceso a archivos del espacio de usuario del que depende el resto del ladrón. Tanto StepSecurity como SafeDep señalaron la capacidad, aunque lo que hace el eBPF aún se está desmantelando.

Las compilaciones de Windows y macOS agregan comprobaciones antidepuración y el ladrón se conecta de forma persistente para sobrevivir a un reinicio: una tarea oculta programada de Windows configurada para reiniciarse cada minuto y un LaunchAgent de macOS que se recarga al iniciar sesión. Sus detalles de comando y control permanecen cifrados en el binario y nunca aparecen en el análisis estático.

El monitoreo del tiempo de ejecución de StepSecurity detectó que el binario caído llegaba a dos direcciones IP codificadas y a la infraestructura Tor, los primeros indicadores de red publicados para la campaña.

jscrambler es una herramienta en tiempo de compilación, que se instala como una dependencia de desarrollo o se ejecuta desde CI. Esos entornos contienen lo que recopila el ladrón: claves de nube, tokens de implementación y código fuente al que puede acceder un proceso de compilación o CI.

Fuente: Paso Seguridad

El paquete recibe alrededor de 15.800 descargas por semana y aún no se sabe cuántas extrajeron la versión comprometida. Esa es una huella mucho menor que la de los paquetes afectados en los grandes compromisos de npm del año pasado, que generan miles de millones de descargas por semana entre ellos.

Sin embargo, para un ladrón cuyo objetivo era construir máquinas, el alcance nunca fue el objetivo. El acceso es.

El gusano Shai-Hulud se ejecutó desde un gancho de instalación para robar tokens y distribuido a través de cientos de paquetes aquel septiembre. Los paquetes de tiza y depuración ampliamente utilizados fueron asumido a través de una cuenta de mantenedor phishing y se utiliza para redirigir pagos criptográficos.

En marzo, una cuenta secuestrada introdujo un troyano multiplataforma en Axios, una biblioteca HTTP con más de 83 millones de descargas semanales. Lo que hace que el momento sea preciso aquí es que npm acababa de moverse en contra de esta ruta exacta: NPM 12 se envió el 8 de julio, tres días antes de este lanzamiento, con los scripts de instalación de dependencias desactivados de forma predeterminada.

En npm 12, un enlace de preinstalación como este no se ejecuta a menos que alguien lo apruebe. Los clientes más antiguos todavía los ejecutan automáticamente.

Desde entonces, la versión 8.15.0 la reemplazó en la parte superior de lista de versiones de npmpublicado desde la misma cuenta de mantenedor y que no muestra ninguna de las alertas de malware activadas por 8.14.0: sin script de instalación, sin binario incluido. Pero la versión 8.14.0 no fue eliminada.

Ciberseguridad

Todavía está en npm, por lo que cualquier archivo de bloqueo o comando fijado en él sigue instalando el ladrón. Sólo se vio afectado el paquete CLI principal; Los complementos jscrambler para webpack, gulp, Metro y grunt se mantuvieron en sus versiones limpias de junio, sin ganchos de instalación.

Que hacer ahora

  1. Bájese de 8.14.0. Vaya a 8.15.0 o fije a 8.13.0 para obtener una versión anterior al incidente y borre jscrambler@8.14.0 de los archivos de bloqueo y cachés.
  2. Averigua si instalaste 8.14.0. Verifique los archivos de bloqueo y los registros del administrador de paquetes para jscrambler@8.14.0 y los registros de CI para cualquier ejecución de dist/setup.js, a partir del 11 de julio. El cargador coloca su carga útil bajo un nombre aleatorio en el directorio temporal, por lo que no hay un nombre binario fijo para buscar; En su lugar, alinee las marcas de tiempo de instalación con los procesos secundarios de Node y la ejecución del directorio temporal. En Windows, consulte el Programador de tareas para ver si hay tareas ocultas; en macOS, inspeccione ~/Library/LaunchAgents en busca de listas desconocidas.
  3. Si 8.14.0 se ejecutó en una máquina, trate todos los secretos a los que pueda acceder como robados, no simplemente expuestos. Rotar claves de nube, tokens de npm y GitHub, y claves de API de MCP y herramientas de IA; revocar sesiones de Discord, Slack, navegador y Bitwarden; y sacar cualquier criptomoneda de las billeteras en ese host. Bloquee las dos IP de comando y control que se enumeran a continuación.

La limpieza fue rápida, pero un ladrón hace su trabajo segundos después de la instalación. Una compilación anclada a 8.14.0, en un cliente anterior que ejecuta scripts de instalación, aún ejecuta la carga útil. Y en cualquier máquina que ya lo ejecutara, los secretos desaparecieron antes de que 8.15.0 llegara a la cima de la lista.

Indicadores de compromiso

Paquete malicioso: jscrambler@8.14.0. Hashes SHA-256 para los archivos agregados y sus cargas útiles descomprimidas:

  • dist/setup.js: a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60
  • dist/intro.js: a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86
  • Carga útil de Linux: fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd
  • Carga útil de Windows: b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903
  • Carga útil de macOS: c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd

Puntos finales de red StepSecurity observados en tiempo de ejecución. Las dos IP son los puntos finales del atacante directo; el binario también llega a la infraestructura Tor, probablemente para conectividad o enrutamiento:

  • IP C2: 37.27.122[.]124
  • IP C2: 57.128.246[.]79
  • Infraestructura Tor: check.torproject[.]org, archivo.torproject[.]organización

Artefactos en el host: un archivo oculto con nombre aleatorio en el directorio temporal del sistema, con el formato . {aleatorio} o . {random}.exe en Windows, además de una tarea programada oculta de Windows o un LaunchAgent de macOS para persistencia.

npm 12 deshabilita la instalación de scripts de forma predeterminada para reducir el riesgo de la cadena de suministro – CYBERDEFENSA.MX

GitHub tiene oficialmente anunciado el lanzamiento de npm versión 12 con los scripts de instalación deshabilitados de forma predeterminada, junto con los tokens de acceso granular (GAT) en desuso diseñados para evitar la autenticación de dos factores (2FA).

La subsidiaria propiedad de Microsoft señaló que los siguientes comportamientos de instalación de npm que solían ejecutarse automáticamente antes se han habilitado:

  • El valor predeterminado de enableScripts está desactivado, lo que significa que los scripts del ciclo de vida de la dependencia (es decir, preinstalación, instalación, postinstalación) y las compilaciones implícitas de node-gyp ya no se ejecutan a menos que se permitan explícitamente.
  • –allow-git tiene el valor predeterminado none, lo que significa que –allow-git tiene el valor predeterminado none: las dependencias de Git (directas o transitivas) ya no se resuelven a menos que se permitan explícitamente.
  • –allow-remote tiene el valor predeterminado none, lo que significa que las dependencias de URL remotas (por ejemplo, archivos tar https) ya no se resuelven a menos que se permitan explícitamente.

Para revisar y aprobar scripts confiables, ahora los usuarios deben ejecutar: «npm aprobar-scripts –allow-scripts-pending» y luego confirmar la lista de permitidos resultante en el archivo «package.json».

Ciberseguridad

Vale la pena señalar que estos cambios se obtuvieron una vista previa el mes pasado, y GitHub recomendó a los desarrolladores actualizar a npm 11.16.0 o más reciente, ejecutar el comando de instalación normal y revisar las advertencias mostradas.

La última versión de npm también introduce dos nuevos cambios:

  • Los GAT de npm configurados para omitir 2FA ya no podrán realizar acciones confidenciales de administración de cuentas, paquetes y organizaciones. Esto incluye crear o eliminar tokens, generar códigos de recuperación y cambiar la contraseña de la cuenta npm, el correo electrónico, el perfil o la configuración 2FA, cambiar el acceso a los paquetes, los mantenedores o la configuración de publicación confiable, y administrar la membresía de la organización y el equipo, así como sus concesiones de paquetes.
  • Los GAT de npm ya no conservarán la capacidad de publicar directamente. Su superficie de publicación se limitará a leer paquetes privados y realizar una publicación, donde un paquete solo se vuelve público después de la aprobación humana de 2FA.

Se espera que el primero de los dos cambios entre en vigor a principios de agosto de 2026. Mientras tanto, se recomienda dejar de usar tokens de derivación de 2FA para las operaciones antes mencionadas y realizarlas de forma interactiva con 2FA. El segundo cambio está previsto para enero de 2027.

«Para prepararse, planee trasladar la publicación automatizada a una publicación confiable (OIDC) o una publicación por etapas con un paso de aprobación humana, en lugar de un token de publicación de larga duración», dijo GitHub.

Ciberseguridad

El desarrollo llega como pnpm 11.10. presenta una nueva configuración «_auth» para configurar la autenticación del registro como un valor único estructurado con clave URL.

«El beneficio de seguridad es que la credencial y el host al que pertenece viajan juntos, y pnpm lee _auth solo desde el entorno o la configuración global, nunca desde los archivos de un proyecto», Socket explicado.

«Eso significa que un pnpm-workspace.yaml o .npmrc malicioso o comprometido dentro de un repositorio no puede apuntar un token válido a un host diferente. Un archivo de proyecto manipulado es una forma común en que los atacantes consiguen un punto de apoyo, y redirigir un token de registro es una ruta directa para robarlo, por lo que cerrar esa ruta elimina la exposición».

GitHub deshabilitará los scripts de instalación de npm de forma predeterminada para detener los ataques a la cadena de suministro

GitHub tiene anunciado lo que dijo son «cambios importantes» que llegarán a la versión 12 de npm, uno de los cuales desactiva los scripts de instalación de forma predeterminada para combatir las amenazas a la cadena de suministro de software.

Los cambios tienen como objetivo combatir las técnicas de ataque que abusan del comando «npm install» para desencadenar la ejecución de código malicioso utilizando ganchos del ciclo de vida de npm. «Npm install» se utiliza para descargar e instalar todas las dependencias necesarias para un proyecto Node.js. La versión 12 está prevista para su lanzamiento el próximo mes.

Al describir los scripts del ciclo de vida en el momento de la instalación como la «superficie de ejecución de código más grande en el ecosistema npm», GitHub dicho el comando «npm install» ejecuta scripts de cada dependencia transitiva, como resultado de lo cual un único paquete comprometido en cualquier parte del árbol de dependencias puede ejecutar código arbitrario en una máquina de desarrollo o en un ejecutor de CI.

Ciberseguridad

Al bloquear tales comportamientos, la idea es requerir la aprobación explícita del usuario antes de que la ejecución del código se inicie automáticamente durante la «instalación npm», en lugar de ser confiable de forma predeterminada. «Hacer la opción de ejecución de script cierra ese camino y lo mantiene a un comando de distancia para los paquetes en los que confía», dijo GitHub.

Los cambios se enumeran a continuación:

  • npm install ya no ejecutará scripts de preinstalación, instalación o postinstalación desde dependencias a menos que estén permitidos explícitamente en el proyecto.
  • npm install ya no resolverá las dependencias de Git, ya sean directas o transitivas, a menos que se permita explícitamente a través de –allow-git.
  • npm install ya no resolverá dependencias de URL remotas, como archivos tar https, a menos que se permita explícitamente a través de –allow-remote.

«Esto incluye compilaciones nativas de node-gyp (es decir, un paquete con un enlace.gyp y sin un script de instalación explícito aún se bloquea, porque npm ejecuta una reconstrucción implícita de node-gyp)», dijo la subsidiaria propiedad de Microsoft sobre los cambios en el comportamiento predeterminado de «allowScripts». «Preparar scripts desde git, las dependencias de archivos y enlaces se bloquean de la misma manera».

Al establecer «–allow-git» en «none» de forma predeterminada, la configuración cierra una ruta de ejecución de código donde el archivo de configuración .npmrc de una dependencia de Git utilizado podría anular el ejecutable de Git, incluso con –ignorar-scriptsuna marca que evita que los paquetes especificados en un archivo package.json ejecuten automáticamente scripts de ciclo de vida integrados durante el proceso de instalación.

Ciberseguridad

GitHub recomienda que los desarrolladores se preparen para estos cambios actualizando a npm 11.16.0 o posterior, ejecutando la instalación normal y revisando las advertencias mostradas.

«Utilice npm aprobar-scripts –allow-scripts-pending para ver qué paquetes tienen scripts, aprobar aquellos en los que confía y confirmar el paquete.json actualizado», agregó. «Después de eso, sólo los scripts que usted aprobó seguirán ejecutándose una vez que actualice. Todo lo que deje sin aprobar se detendrá».

A principios de este año, npm también introdujo «min-release-age», una configuración que le dice a npm que rechace cualquier versión de paquete publicada menos de un número específico de días como protección contra paquetes maliciosos recientemente publicados.

npm agrega controles de instalación de paquetes y publicación controlados por 2FA contra ataques a la cadena de suministro – CYBERDEFENSA.MX

GitHub ha implementado nuevos controles para npm para mejorar la seguridad de la cadena de suministro de software, brindando a los mantenedores la capacidad de aprobar explícitamente una versión antes de que los paquetes estén disponibles públicamente para su instalación.

La función, denominada publicación por etapas, ahora está disponible de forma generalizada en npm. Exige que un mantenedor humano pase un desafío de autenticación de dos factores (2FA) para aprobar un paquete antes de enviarlo a npmjs.[.]com.

«En lugar de una publicación directa que pone inmediatamente a disposición de los consumidores una versión del paquete, el tarball prediseñado se carga en una cola de espera donde un responsable de mantenimiento debe aprobarlo explícitamente antes de que sea instalable», GitHub dicho.

La subsidiaria propiedad de Microsoft dijo que el cambio garantiza una «prueba de presencia» para cada publicación, incluidas aquellas que provienen de flujos de trabajo CI/CD no interactivos y publicaciones confiables con autenticación OpenID Connect (OIDC).

Antes de usar publicación en escenalos mantenedores de paquetes deben cumplir los siguientes criterios:

  • Tener acceso de publicación al paquete.
  • El paquete ya existe en el registro npm, lo que significa que no se puede preparar un paquete nuevo
  • 2FA está habilitado para la cuenta

Los desarrolladores pueden utilizar el comando «npm stage Publish» desde el directorio raíz del paquete para enviarlo a un área de preparación. Para utilizar este comando, es esencial actualizar a npm CLI 11.15.0 o posterior. Para una protección óptima, GitHub recomienda que la publicación por etapas se combine con publicación confiable utilizando OIDC.

Ciberseguridad

Una segunda actualización centrada en npm se relaciona con la introducción de tres nuevos indicadores de fuente de instalación junto con el indicador existente -allow-git –

  • –allow-file: Controla las instalaciones desde rutas de archivos locales y archivos tar locales
  • –allow-remote: controla las instalaciones desde URL remotas, incluidos archivos tar https
  • –allow-directory: Controla las instalaciones desde directorios locales

Las banderas permiten a los desarrolladores «aplicar el mismo enfoque de lista permitida explícita a cada fuente de instalación que no sea del registro», dijo GitHub.

El desarrollo se produce en medio de un aumento masivo de ataques a la cadena de suministro de software dirigidos a ecosistemas de código abierto en los últimos meses, con un grupo cibercriminal conocido como TeamPCP involucrado en envenenar paquetes populares a una escala sin precedentes a través de un ciclo de compromisos que se perpetúa a sí mismo.