ChainDrop: procedencia válida en más de 400 paquetes npm, y hooks de Claude Code que no requieren npm install

El 4 de agosto de 2026, atacantes tomaron el control de la cuenta de GitHub detrás de keyv, una biblioteca de caché que, según Elastic Security Labs, se había descargado más de 600 millones de veces el mes anterior. Wiz Research y Orca Security registran ambos que se subieron archivos maliciosos directamente a la rama principal de keyv, y que el flujo de trabajo de GitHub Actions del propio proyecto compiló y publicó después la versión envenenada, de modo que llegó a npm con procedencia válida, la atestación que las herramientas de la cadena de suministro usan para determinar si un paquete es confiable. Un gusano autorreplicante que los investigadores llaman ChainDrop usó después tokens npm robados para repetir el truco en los paquetes de otros mantenedores: Elastic contabilizó más de 400 paquetes únicos al 6 de agosto, Microsoft Threat Intelligence describió la misma campaña el 4 de agosto, y la Agencia de Ciberseguridad de Singapur contabilizó más de 1.300 versiones de paquetes comprometidas con una suma de 2.000 millones de descargas mensuales. Tanto Elastic como Microsoft describen hooks que se vuelven a ejecutar cuando se abre un repositorio en Claude Code o Visual Studio Code. La lista completa de fuentes, la calificación de gravedad y la evaluación de confianza del registro se encuentran en el archivo de incidentes de IA, junto con las demás entradas de cadena de suministro de npm y de herramientas para desarrolladores archivadas en torno a él.

Cómo una canalización de lanzamiento legítima firmó su propio compromiso

Wiz Research reconstruye los primeros minutos: desde las 09:00 UTC del 4 de agosto el atacante utilizó una identidad comprometida para introducir payloads de persistencia de IDE en el repositorio keyv y, poco después, publicó una nueva versión de keyv que contenía el payload. Wiz identifica a la parte comprometida como una cuenta de mantenedor de GitHub y afirma que siguieron múltiples paquetes del ecosistema keyv y cacheable.

El informe de respuesta rápida de Orca Security es más específico sobre la ruta de firma. Según este, el atacante subió dos archivos maliciosos — setup.mjs y Math_Symbol.js — directamente a la rama principal y publicó de inmediato nuevas versiones. Como esas versiones se compilaron mediante los flujos de trabajo de GitHub Actions de la cuenta comprometida, las versiones envenenadas se publicaron en npm con firmas de procedencia válidas, evitando los controles estándar de integridad de la cadena de suministro. Zscaler ThreatLabz, un equipo de investigación independiente que no figura entre las fuentes citadas en el registro, llega a la misma conclusión y le asigna un nivel: el malicioso keyv 6.0.0 llevaba una procedencia válida SLSA Build Level 3 porque el atacante controlaba el repositorio de origen. BleepingComputer, que informó sobre la campaña ese mismo día, registra el mismo mecanismo — archivos maliciosos subidos directamente a las ramas principales de los proyectos, nuevas versiones generadas y procedencia válida porque las compilaciones se ejecutaron mediante flujos de trabajo legítimos de GitHub Actions.

El análisis de Microsoft añade un detalle que parece una contradicción y no lo es. En la fase de propagación del gusano, Microsoft Threat Intelligence descubrió que muchas versiones maliciosas no tenían ningún commit de código fuente, pull request, etiqueta o versión legítima correspondiente, lo que indicaba que los atacantes modificaban y publicaban los tarballs del paquete directamente en lugar de comprometer cada repositorio de código fuente público. Leídas en conjunto, las fuentes describen dos regímenes de firma dentro de una misma campaña: las primeras versiones de keyv pasaron por el pipeline de CI real de la víctima y llevan atestaciones que lo corroboran, mientras que las versiones posteriores del gusano se ensamblaron y publicaron en gran medida con tokens de registro robados, sin dejar ningún rastro en el código fuente. La propia observación de Microsoft es que el patrón de tarball directo explica por qué las versiones maliciosas aparecían con frecuencia como un incremento ordinario de versión de parche sin commits de código fuente ni pull requests correspondientes.

La incómoda lección la expone claramente Zscaler: la procedencia valida el proceso de compilación, no la identidad de la cuenta ni la integridad del sistema de CI que lo ejecuta. También admite una laguna que importa a cualquiera que reconstruya el incidente: el mecanismo exacto de toma de control de cuenta que utilizó el atacante se desconocía en el momento de su análisis.

Qué se ejecuta en npm install: preinstall, Bun 1.3.13 y un colector de 300 patrones

Elastic Security Labs describe el desencadenante como un preinstall hook en package.json, que abusa de una funcionalidad legítima de npm que ejecuta comandos arbitrarios antes de que un paquete termine de instalarse, sin requerir ninguna interacción adicional por parte de la víctima. El hook lanza setup.mjs, que comprueba si el entorno de ejecución de JavaScript Bun ya está presente. Si no lo está, el dropper detecta la plataforma y la arquitectura de la máquina, descarga Bun v1.3.13 desde la página oficial de versiones, lo extrae, lo usa para ejecutar la carga útil y luego elimina el directorio temporal para borrar sus rastros. Wiz identificó de forma independiente el agente de usuario Bun/1.3.13 que realizaba las llamadas maliciosas. El dropper es multiplataforma y está dirigido a Linux, macOS y Windows.

El payload está fuertemente ofuscado, y las fuentes difieren ligeramente en cuanto a su tamaño: Elastic lo sitúa en 711 kilobytes, Orca Security en 728 KB. Utiliza aplanamiento de flujo de control y un esquema de codificación de cadenas Base91, y contiene cadenas temáticas de Dune — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — que, según señala Elastic, guardan similitudes con campañas anteriores de Shai-Hulud.

El análisis conductual de Microsoft añade dos detalles que conviene tener en cuenta. El payload comprueba primero su entorno y se cierra en sistemas de idioma ruso, evita instancias duplicadas y lanza una copia en segundo plano independiente en estaciones de trabajo de desarrolladores; dentro de CI permanece vinculado al trabajo activo para poder acceder a secretos del flujo de trabajo, credenciales del runner y permisos de publicación de OpenID Connect.

El collector es donde el incidente se convierte en una historia de herramientas de IA en lugar de una historia genérica de credenciales. Elastic dice que escanea más de 300 patrones únicos en los almacenes de credenciales de una máquina de desarrollador, y que el objetivo notable son credenciales de herramientas de IA: Anthropic, Claude, Codex, Cursor, OpenAI y Gemini. También toma credenciales de AWS, GCP, Azure y Alibaba Cloud, tokens de acceso personal de GitHub, tokens JWT y de sesión, tokens de HashiCorp Vault, claves privadas SSH, tokens de cuenta de servicio de Kubernetes y tokens de npm. Wiz informa que la lista de objetivos se había ampliado en casi un 70 % con respecto al código anterior de Mini Shai-Hulud en el que se basa, con nuevas incorporaciones que incluyen almacenes de credenciales de agentes de IA para Claude, OpenAI, Codex, Cursor y Gemini, almacenes de claves de criptomonedas para Foundry, Solana y Monero, master.key de Jenkins, secretos de Argo CD y Harbor, configuraciones de CLI de Alibaba y Tencent, y /etc/shadow.

Tanto Microsoft como Elastic describen el mismo diseño de exfiltración. Los resultados se serializan como JSON, se comprimen con gzip y se cifran con una clave AES-256-GCM generada aleatoriamente, y esa clave se envuelve con la clave pública RSA del atacante. La carga útil no codifica de forma fija su dominio de mando y control: Elastic afirma que consulta un contrato inteligente de Ethereum en 0xE1f2395ee43e45A1556EC6438a88c31B83493103 para obtener el endpoint actual en tiempo de ejecución, de modo que la infraestructura se puede rotar sin tocar el malware. Si eso falla, busca un marcador firmado criptográficamente — thebeautifulmarchoftime — en el historial de commits de GitHub y valida el dominio contra una clave RSA incrustada. Si ambos fallan, exfiltra datos mediante un repositorio público de GitHub que crea la propia cuenta de la víctima, descrito como "Shai-Hulud: Here We Go Again". Microsoft señala que una ruta de respaldo codifica un token de GitHub robado con doble Base64 en lugar de cifrarlo.

La propagación está condicionada por la calidad del token. Elastic informa que el gusano se activa solo cuando el barrido de credenciales encuentra un token de npm con permiso de escritura para paquetes y la capacidad de publicar sin autenticación de dos factores; luego descarga el último tarball de cada paquete escribible, se inyecta, incrementa la versión de parche y vuelve a publicar. BleepingComputer añade que cada token se valida en tiempo real contra el endpoint whoami del registro antes de ser robado. Esa rutina es lo que convirtió una identidad comprometida en cientos de versiones publicadas, y es la razón por la que las versiones maliciosas parecen incrementos de parche ordinarios.

La ruta de infección que no requiere npm install

El hallazgo que separa esta campaña de los gusanos npm anteriores es que la instalación ya no es la única vía de entrada. Elastic describe dos vías de ejecución adicionales dirigidas a usuarios de herramientas de programación con IA. Un SessionStarthook .claude/settings.json ejecuta node .claude/setup.mjs cuando se inicia una nueva sesión de Claude. Para VS Code, una folderOpentarea .vscode/tasks.json ejecuta node .vscode/setup.mjs cuando se abre un repositorio infectado. El análisis de Microsoft enumera los mismos cuatro artefactos — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json y .vscode/setup.mjs — y los describe como una vía de infección secundaria que puede reiniciar la carga útil después de que se haya completado la instalación original de npm.

La condición que amplía esto drásticamente está en las credenciales robadas. Cuando un token de GitHub App está entre ellas, Elastic informa que el gusano hace commit de los hooks maliciosos en hasta 50 ramas por repositorio accesible, inyectando .claude/settings.json y .vscode/tasks.json en cada una. La conclusión de Elastic es que un desarrollador que clone una de esas ramas y la abra puede infectarse con solo abrir el proyecto — sin instalación de paquetes y, por tanto, sin ninguna defensa de script de instalación en la ruta.

La evaluación de Zscaler es que los hooks de persistencia sobreviven a la eliminación del paquete y se vuelven a ejecutar simplemente al abrir el proyecto en VS Code o Claude Code, lo que elude--ignore-scripts que muchos equipos adoptaron tras los gusanos npm anteriores. Su recomendación es directa: tratar los archivos de configuración de IDE y agentes de IA — .claude/, .cursor/, .vscode/, .gemini/ — como código ejecutable, revisados con el mismo rigor que el código fuente.

Hay una huella digital para la mitad del ataque relacionada con el repositorio. Elastic informa que los commits generados por el gusano pueden identificarse por el nombre del autor claude y el mensaje de commit chore: update config, y Wiz registra la misma cadena de mensaje. Elastic añade que el mensaje de commit también llevaba el token de GitHub robado junto a una cadena de intimidación — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — que interpreta como un intento de asustar a los desarrolladores para que no revoquen el token. Wiz registra la misma cadena en los commits iniciales, con el mensaje más corto intercambiado en los commits que introducen los hooks del IDE.

Los recuentos no concuerdan, y eso no es una contradicción.

Cada cifra publicada sobre el radio de impacto está asociada a una unidad diferente, y las unidades no son intercambiables. Elastic Security Labs, en una publicación del 6 de agosto, contó más de 400 paquetes npm únicos comprometidos. Microsoft Threat Intelligence describió más de 400 paquetes de múltiples publicadores no relacionados. Aikido, citado por BleepingComputer, lo situó en al menos 868 paquetes en 1.381 versiones. Orca Security informa de 10 paquetes keyv y cacheable directamente envenenados con más de 619 millones de descargas mensuales, y luego 868 paquetes adicionales y 1.381 versiones alcanzados por el gusano, lo que supone más de 2.000 millones de instalaciones mensuales. El aviso AD-2026-009 de la CSA de Singapur, con fecha del 6 de agosto, registra más de 1.300 versiones de paquetes comprometidas que representan un total combinado de 2.000 millones de descargas mensuales.

Esos son tres denominadores distintos —paquetes, versiones de paquetes y volumen mensual de descargas— tomados en tres momentos distintos de una campaña que seguía en curso. La explicación de Zscaler sobre la velocidad explica por qué divergen: afirma que el gusano se autopropagó a más de 400 paquetes en menos de cuatro horas y que, en su punto máximo, publicaba aproximadamente un paquete infectado por segundo. Tratar un recuento posterior como una corrección de uno anterior sería incorrecto; cada uno es una instantánea, y ninguna de las fuentes citadas afirma un total final.

Las cifras de exposición de Elastic a nivel de librería son las que más se citan y las menos ambiguas. Reporta keyv por sí solo con más de 600 millones de descargas el mes anterior, con flat-cache cerca de 580 millones, cacheable-request más de 137 millones, cacheable más de 30 millones y cache-manager más de 16 millones. El aviso de CSA enumera las versiones comprometidas específicas, entre ellas keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 y ecto 5.0.1.

La trampa de la revocación

Los equipos de respuesta que instalaron una versión afectada se enfrentan a un segundo problema después del primero. Elastic informa que, en una ruta de respaldo condicional de GitHub, el payload intenta instalar un componente de monitoreo de tokens que mantiene el acceso a las credenciales y contiene un controlador destructivo si se revoca el token monitoreado. Zscaler describe el mecanismo con detalle operativo y lo denomina trampa de revocación de tokens: el gusano instala un proceso en segundo plano que consulta la API de GitHub cada 60 segundos con el token robado, y si el token devuelve un error 4xx —lo que significa que la víctima lo ha revocado— se activa una carga destructiva secundaria que, según la variante, puede incluir ejecución remota de código o eliminación del directorio de inicio del usuario.

Wiz añade que el interruptor de hombre muerto se arma de forma selectiva en función de una respuesta del servidor de mando y control: el operador puede devolver un valor que especifique qué comando armar y qué token debe vigilar el interruptor para detectar una revocación. Wiz también señala que el monitor busca una respuesta válida del punto de conexión del usuario, por lo que cualquier tipo de token válido allí puede servir como desencadenante.

La consecuencia práctica queda registrada por BleepingComputer y por la guía de Aikido que este cita: una estación de trabajo de desarrollador o un runner de CI/CD que instaló una versión afectada debe tratarse como comprometido incluso si el paquete se eliminó posteriormente, porque la ejecución de segunda etapa puede haber expuesto tokens y socavado la integridad de la compilación. La guía de Microsoft llega al mismo punto desde el lado de la compilación, advirtiendo que las organizaciones que instalaron un paquete afectado con los scripts de ciclo de vida habilitados deben tratar la estación de trabajo o el runner de compilación como potencialmente comprometidos y reconstruir los sistemas afectados y los artefactos derivados desde fuentes confiables.

Lo que está establecido, lo que se evalúa y lo que nadie ha demostrado

El registro principal y cinco análisis independientes convergen en la mecánica, y las afirmaciones mecánicas son la parte más sólida del archivo.

• La cuenta de GitHub del mantenedor de keyv fue comprometida, y se enviaron archivos maliciosos directamente a main antes de que se publicara una versión, el 4 de agosto de 2026 — según informes coincidentes de Wiz, Orca Security, BleepingComputer y CSA Singapore.

• Al menos keyv 6.0.0 llegó a npm a través de la propia canalización CI de la víctima, con procedencia válida, y con Zscaler especificando una atestación SLSA Build Level 3. Esta es la afirmación que hace que el incidente sea notable, y está corroborada por tres organizaciones que no coautoraron el trabajo de las demás.

• Un hook de preinstalación ejecutó setup.mjs, que descargó Bun v1.3.13 y ejecutó una carga útil ofuscada que escaneó más de 300 patrones de credenciales, incluidas credenciales de herramientas de codificación con IA — Elastic y Wiz coinciden tanto en la versión del entorno de ejecución como en la lista de credenciales dirigidas a IA.

• Los hooks escritos en .claude/settings.json y .vscode/tasks.json se ejecutan al iniciar la sesión y al abrir la carpeta, y un token de GitHub App amplió eso a hasta 50 ramas por repositorio accesible — el hallazgo de Elastic y la base de su afirmación de que un desarrollador puede infectarse al abrir un repositorio.

Más de 400 paquetes únicos se vieron comprometidos en cuestión de días, y CSA Singapore, un regulador nacional, publicó el aviso AD-2026-009 el 6 de agosto de 2026, en el que se enumeran las versiones afectadas y los indicadores.

Lo que las fuentes consideran una evaluación más que un hecho debería etiquetarse. Wiz describe el payload como un descendiente de la familia de malware Shai-Hulud "Mini", construido sobre repositorios públicos Shai-Hulud-Open-Source publicados por TeamPCP, con algunos cambios cruciales; Orca Security atribuye el ataque a TeamPCP; Zscaler vincula ChainDrop con TeamPCP y lo sitúa en un linaje que se remonta a septiembre de 2025. Eso es un consenso de atribución de proveedores, no algo que un documento primario citado demuestre sobre una persona o un grupo nombrados.

Tres cosas que ninguna fuente citada establece y que este artículo no completa. En primer lugar, cómo se tomó el control de la cuenta del mantenedor: Zscaler afirma claramente que el mecanismo exacto se desconocía en el momento de su análisis. En segundo lugar, un total final único: las cifras 400, 868 y 1.300 cuentan paquetes, paquetes con versiones y versiones en momentos distintos, y ninguna fuente afirma que la campaña esté cerrada. En tercer lugar, y lo más importante para la afirmación específica sobre IA en este registro, ninguna fuente citada informa de un caso confirmado en el que una credencial robada de Anthropic, Codex, Cursor, Gemini u OpenAI se haya reutilizado contra una cuenta de proveedor. Lo que está documentado es la intención y la capacidad —una lista explícita de objetivos y un recolector creado para alcanzarla—, no una brecha posterior demostrada en los sistemas de un proveedor de IA.

Qué cambió después — y qué tiene que hacer quien responde

El remedio más concreto que consta en el registro es un cambio de plataforma. Elastic recomienda actualizar a npm 12 o posterior, que bloquea los hooks de preinstalación de forma predeterminada; la guía de Microsoft recomienda de forma independiente npm CLI v12 y la min-release-age, una función que retrasa las nuevas versiones lo suficiente para que la comunidad detecte una versión comprometida antes de que llegue a una compilación.

Además de eso, los pasos de respuesta que publican las fuentes se solapan en gran medida.

• Elastic: revoque todos los tokens de GitHub, incluidos los tokens de sesión, en las máquinas afectadas; revoque y regenere los tokens de npm, especialmente los tokens de automatización con permisos de escritura y omisión de la autenticación de dos factores; busque en los repositorios commits no autorizados con el mensaje chore: update config from claude@users.noreply.github.com; rote los secretos de nube, Kubernetes, Vault, herramientas de IA y CI/CD; habilite la autenticación de dos factores en las cuentas de npm.

• Microsoft: purgar las cachés de npm y yarn en los endpoints afectados y en los hosts de compilación, fijar versiones buenas conocidas, revisar los lockfiles y artefactos en busca de las versiones comprometidas, incluidas las referencias transitivas, reconstruir las imágenes base compartidas y los runners de compilación de referencia, y revisar los alcances de tokens, las aprobaciones de workflows y la procedencia de las releases, porque el incidente es consistente con abuso de la pipeline CI/CD mediante publicación OIDC.

• CSA Singapore: elimine las versiones afectadas de los entornos de desarrollo, compilación y CI/CD; trate los sistemas afectados como comprometidos y reconstrúyalos; rote las credenciales; revise los entornos de nube y de código fuente en busca de acceso no autorizado; supervise los indicadores publicados; y refuerce las listas de permitidos, la verificación de integridad y los controles de procedencia.

• Zscaler: trata .claude/, .cursor/, .vscode/ y .gemini/ como código ejecutable, y deja de tratar la procedencia de SLSA o Sigstore como prueba de seguridad; en su lugar, combínala con detección de anomalías en el comportamiento de publicación, como publicación fuera del horario laboral, publicación masiva de versiones y publicadores primerizos.

El registro no contiene un resultado de remediación. Ninguna fuente citada informa de que las versiones maliciosas hayan sido eliminadas por completo, de una recuperación de cuenta, de una detención o de una medida regulatoria de cumplimiento; el aviso de CSA es una notificación para los defensores, no una conclusión en contra de una parte.

Lo que el incidente cambia es una clasificación. Un archivo de configuración de herramientas para desarrolladores es una ruta de ejecución, y que un editor abra una carpeta es un evento de ejecución. Y una atestación de procedencia es una declaración sobre qué pipeline produjo un paquete — no sobre quién tenía las claves cuando se ejecutó ese pipeline, que es precisamente la brecha por la que se escapó la primera versión de keyv.