El gusano ChainDrop en npm infecta 1.300 paquetes

Una campaña de malware autopropagante en npm llamada ChainDrop ha comprometido más de 1.300 paquetes con un total combinado de 2.000 millones de descargas mensuales, convirtiendo la violación de la cuenta de un único mantenedor en un amplio ataque a la cadena de suministro de software.

La campaña comenzó después de que un atacante comprometiera la cuenta de GitHub del mantenedor de Keyv. Luego se propagó a utilidades de caché relacionadas, incluidas Cacheable, flat-cache y file-entry-cache, así como a paquetes asociados a Deliveroo, Ornikar, OneReach, Picsart, Qlik y ServiceTitan.

Varias empresas de seguridad de aplicaciones identificaron el malware como un gusano basado en Shai-Hulud. Aikido informó que al menos 868 paquetes en 1.381 versiones habían sido comprometidos. Esa cifra no coincide con el conteo de paquetes más amplio reportado para la campaña, lo que sugiere que los investigadores estaban midiendo porciones o etapas diferentes del ataque.

Recomendado

Las passkeys de Google enfrentan un nuevo ataque Pass-ta-key

Cómo ChainDrop infecta las instalaciones de npm

Los atacantes introdujeron archivos maliciosos en las ramas principales de GitHub de los proyectos y generaron nuevas versiones en npm mediante los flujos de trabajo legítimos de GitHub Actions de los proyectos. Como resultado, los paquetes envenenados conservaron información de procedencia válida —una señal que normalmente ayuda a los consumidores a distinguir compilaciones oficiales de artefactos manipulados.

Cada paquete afectado contiene dos archivos clave:

• setup.mjs, un dropper
• Math_Symbol.js o, en algunos paquetes, math_init.js, la carga útil ofuscada que roba información

La configuración del paquete también añade un script preinstall:

''json “preinstall”: “node setup.mjs” ''

Eso significa que el dropper se ejecuta automáticamente cuando alguien instala una versión afectada, antes de que la instalación se complete.

×

setup.mjs descarga el runtime Bun de JavaScript desde una release oficial de GitHub, lo usa para ejecutar el JavaScript malicioso y luego elimina el directorio temporal del runtime. La carga útil también puede propagar la infección a paquetes mantenidos por terceros cuando esos paquetes se usan en un entorno comprometido.

Cualquiera que ejecutara npm install contra una versión afectada habría tenido setup.mjs ejecutándose automáticamente antes de que se completara su instalación,

Credenciales dirigidas en sistemas de desarrollo

El malware valida tokens en tiempo real contra registry.npmjs[.]org/-/whoami antes de robarlos. Busca en estaciones de trabajo de desarrolladores y runners de CI/CD infectados credenciales que podrían proporcionar acceso a repositorios de código adicionales y paquetes de npm.

Los datos robados pueden incluir:

• Variables de entorno del proceso y archivos locales de configuración o credenciales
• Tokens de acceso personal de GitHub, tokens de workflow y tokens ghp_, gho_ y ghs_
• Tokens de npm que comienzan con npm_
• Secrets de GitHub Actions, incluidos los valores marcados “isSecret”: true en runners autohospedados
• Credenciales de AWS, valores de SSM Parameter Store solicitados con desencriptación, y secretos de Secrets Manager
• Secrets de Kubernetes de espacios de nombres accesibles
• Tokens de HashiCorp Vault y secretos KV
• Credenciales de bases de datos, claves privadas y credenciales de Stripe, Slack, Twilio, Azure y Google Cloud

El malware de robo de información cifra la información recopilada y la envía a un repositorio público de GitHub descrito como “Shai-Hulud: Here We Go Again.” La empresa de seguridad en la nube Wiz también identificó npm-cache[.]com como un dominio de exfiltración y recomendó tratarlo como un indicador fuerte de compromiso.

La combinación de credenciales de npm, tokens de GitHub, secretos de la nube y acceso a CI/CD le da al gusano una vía para seguir propagándose más allá del conjunto original de paquetes. En términos prácticos, una instalación de paquete puede convertirse en un compromiso del entorno de compilación y de los repositorios o servicios a los que ese entorno puede acceder.

Qué deben hacer ahora los proyectos afectados

Los administradores deben tratar cualquier estación de trabajo de desarrollador o runner de CI/CD que haya instalado una versión afectada como comprometida, incluso si el paquete se eliminó después. La respuesta recomendada es:

• Reconstruir el sistema a partir de una copia de seguridad conocida como segura o desde cero.
• Rotar todos los tokens accesibles desde el entorno afectado.
• Revisar los registros en busca de accesos no autorizados.
• Inspeccionar los repositorios de código fuente en busca de commits inesperados u otros cambios.
• Comprobar el historial publicado de paquetes y la actividad de red frente a los indicadores de compromiso disponibles.

La campaña aún está en desarrollo, y el número de paquetes afectados y las versiones maliciosas exactas pueden crecer. Empresas de seguridad como Wiz, StepSecurity, Aikido, Socket y Ox Security han publicado listas de paquetes e indicadores como hashes de archivos maliciosos y datos de red.

El incidente también demuestra por qué la procedencia por sí sola no puede establecer que una versión sea segura: los atacantes utilizaron flujos de trabajo legítimos de GitHub Actions para producir versiones que conservaron procedencia válida. La lista de dependencias permitidas, las comprobaciones de integridad y los controles de procedencia siguen siendo defensas recomendadas, pero deben combinarse con monitorización y rotación rápida de credenciales —el mismo tipo de defensas basadas en el tiempo y en la integridad de las versiones tratadas en Los cambios en la cadena de suministro de GitHub y PyPI.