ChainDrop ha alertado sobre un compromiso de paquetes npm que afectó a 444 paquetes y más de 1,300 versiones maliciosas. La campaña, de naturaleza autopropagable, comenzó cuando atacantes tomaron el control de la cuenta de GitHub vinculada a la librería de almacenamiento en caché Keyv. Utilizando tokens de publicación robados, la operación logró impactar paquetes que suman más de dos mil millones de instalaciones mensuales.

ChainDrop ha convertido la vulneración de un paquete npm en una advertencia sobre las máquinas de los desarrolladores.

La campaña de autopropagación envenenó 444 paquetes y más de 1,300 versiones maliciosas después de que los atacantes tomaran el control de la cuenta de GitHub vinculada a la librería de almacenamiento en caché Keyv.

Los paquetes afectados representaban más de dos mil millones de instalaciones mensuales. La operación se propagó a través de tokens de publicación de npm robados y canales de lanzamiento legítimos.

También fue más allá de la instalación de paquetes: los atacantes añadieron una configuración de repositorio que podía ejecutarse cuando un desarrollador abría un proyecto en VS Code o iniciaba una sesión de Claude Code. Por lo tanto, un git clone y la apertura del proyecto podrían generar una exposición.

Abby Kearns señaló en un informe que la distinción fue la elección del atacante de omitir el paso de instalación que supervisan los controles de la cadena de suministro.

Microsoft llama a la campaña ChainDrop, mientras que otros investigadores la rastrean como Mini Shai-Hulud, siguiendo patrones vistos en la reciente campaña Mini Shai-Hulud.

El punto de entrada inicial no ha sido revelado. Aun así, el incidente muestra cómo la cuenta de un mantenedor comprometida puede convertir la publicación confiable, los flujos de trabajo automatizados y las herramientas de desarrollo en un canal de distribución.

También plantea si los equipos de ingeniería inspeccionan los repositorios solo como código fuente, en lugar de contenido que puede instruir a las herramientas locales para actuar.

Gusano npm ChainDrop

El ataque comenzó el 4 de agosto con el compromiso de la cuenta de GitHub detrás de Keyv y paquetes que incluyen cacheable, flat-cache y file-entry-cache.

Los atacantes utilizaron credenciales robadas para publicar versiones alteradas y luego recolectaron más accesos de publicación para expandir la infección.

Los proyectos que rastreaban las versiones principales más recientes estaban en riesgo particular, mientras que las versiones fijadas más antiguas estaban protegidas.

Los lanzamientos parecían confiables porque llevaban atestaciones de procedencia válidas.

Se publicaron a través de un flujo de trabajo de GitHub Actions configurado como un publicador confiable de npm, por lo que los registros mostraban que una identidad aprobada realizó el lanzamiento.

El problema estaba "aguas arriba": el código malicioso había entrado en el repositorio antes de que se ejecutara el flujo de trabajo, una lección reflejada en la debilidad del flujo de trabajo de GitHub Actions reportada a principios de este año.

Esa distinción es importante porque la procedencia puede confirmar el origen de una compilación, pero no puede garantizar que la computadora, cuenta o repositorio que la produjo estuviera limpio.

En este caso, no se falsificó ninguna firma ni se rompió ningún canal de publicación. Los atacantes abusaron de un acceso que el ecosistema fue diseñado para confiar.

Para los mantenedores, la respuesta fue compleja y consumió mucho tiempo. El mantenedor de Keyv limpió las máquinas afectadas, desactivó GitHub Actions y la publicación confiable, retiró las versiones comprometidas, eliminó ramas y etiquetas maliciosas, y reinició las ramas impactadas.

Tú y tu equipo deberían igualmente revocar y rotar las credenciales expuestas, revisar los permisos del flujo de trabajo y reconstruir los entornos de desarrollo o CI afectados desde un estado conocido como limpio.

Los archivos del repositorio se convierten en una ruta de ejecución

ChainDrop también colocó dos archivos de configuración en repositorios accesibles en hasta 50 ramas. Uno proporcionaba un gancho SessionStart de Claude Code y el otro definía una tarea de VS Code para ejecutarse cuando se abría una carpeta.

Cada uno podría lanzar un dropper desde el directorio de la otra herramienta, permitiendo la ejecución sin un npm install o compilación.

Este enfoque escapa a la vista de muchos escáneres de dependencias. Esos productos suelen examinar manifiestos y archivos de bloqueo para identificar paquetes descargados, no la configuración del proyecto que describe tareas del editor o el comportamiento de herramientas de codificación con IA.

El riesgo es similar al de un incidente de acción de automatización comprometida, donde la automatización de desarrollo confiable se convierte en la ruta hacia un acceso sensible.

La confianza en el espacio de trabajo de VS Code y las comprobaciones de confianza de Claude Code pueden detener la actividad automática en un proyecto no confiable. Pero el peligro aumenta después de que tú, como desarrollador, ya hayas marcado una descarga familiar como confiable.

Kearns te aconseja a ti y a tu equipo buscar en cada rama, no solo en la rama principal, cualquier configuración de repositorio inesperada y comparar las versiones resueltas con los lanzamientos afectados.

Las organizaciones deberían tratar la configuración suministrada por el repositorio como contenido ejecutable y añadir esas rutas a las revisiones, el monitoreo y las comprobaciones de respuesta a incidentes.

Deberían hacer un inventario de las herramientas de codificación, examinar los archivos que se leen al abrir un proyecto, restringir los tokens de alto valor y estar atentos a vulneraciones anteriores de paquetes npm que puedan señalar robos de credenciales similares.

ChainDrop demuestra que un árbol de dependencias seguro por sí solo ya no garantiza un espacio de trabajo de desarrollador seguro.

Fuentes:
https://cybersecuritynews.com/chaindrop-npm-worm/