ChainDrop: el gusano que envenenó la cadena de suministro de JavaScript
El 4 de agosto de 2026, entre las 6:40 y las 10:20 de la mañana (hora argentina), miles de
proyectos de JavaScript quedaron expuestos sin que nadie tocara una sola línea de su propio código. Los
atacantes no vulneraron el lenguaje ni los servidores: envenenaron los paquetes que los desarrolladores
descargan automáticamente todos los días.
La campaña fue bautizada ChainDrop y se vincula con la familia de malware Shai-Hulud. Empezó
con paquetes muy usados para manejo de caché, como keyv y cacheable, y se extendió
a otros como flat-cache, file-entry-cache y cache-manager.
Cómo operó el ataque
Los atacantes se apoderaron de la cuenta de un mantenedor, modificaron los repositorios y publicaron versiones nuevas con apariencia legítima. Cuando un desarrollador corría un simple npm install o pnpm install, el paquete podía disparar un script automático (preinstall) que salía a la caza de:
Lo más grave: con las credenciales robadas, el malware intentaba publicar versiones infectadas de otros paquetes. Cada víctima se convertía en un nuevo foco de contagio. Por eso se lo describe como un gusano, no como un virus aislado.
Por qué fue tan peligroso
El ataque explotó tres costumbres muy extendidas en el desarrollo moderno:
Una empresa podía no haber instalado keyv jamás y recibirlo igual, escondido cuatro niveles abajo en el árbol de dependencias: la aplicación usa ESLint, ESLint usa file-entry-cache, este usa flat-cache, y flat-cache usa keyv. Revisar solo el package.json no alcanza: hay que mirar los lockfiles y el árbol completo.
La trampa de la firma válida
Un detalle inquietante: algunas versiones comprometidas se publicaron mediante flujos legítimos de GitHub
Actions. Tenían firma válida, procedencia válida y salían del repositorio correcto. La firma probaba que el
paquete lo construyó el pipeline autorizado, pero no que el código fuente estuviera
limpio.
La moraleja es incómoda pero útil: la procedencia importa, y aun así no reemplaza la revisión del código y
de los permisos del pipeline.
¿Cómo saber si tu proyecto está afectado?
Conviene decirlo claro: npm audit por sí solo no alcanza. Está pensado para vulnerabilidades ya registradas, y un paquete malicioso recién publicado puede no tener todavía ningún CVE.
Si encontraste una versión comprometida
Cómo blindarte para la próxima
Y como regla general: tokens con permisos mínimos, alcance limitado, duración corta y rotación automática. Cada actualización de dependencia debería revisarse antes de aceptarse: versión exacta, quién la publicó, si agregó scripts nuevos y si cambió la procedencia.
Conclusión
ChainDrop no fue un virus dentro de JavaScript: fue un golpe directo a la confianza que sostiene todo el
ecosistema de paquetes. Una dependencia diminuta, que nadie eligió instalar, puede terminar con acceso a la
computadora del desarrollador, los secretos del CI/CD, los repositorios y las cuentas cloud de una empresa
entera.
Ninguna medida aislada frena todos los ataques. Pero la combinación de lockfiles revisados, scripts
bloqueados por defecto, período de espera, permisos mínimos y rotación rápida de credenciales convierte una
infección casi automática en algo mucho más difícil de lograr.