Vuelve Shai-Hulud: el gusano ChainDrop ataca npm e infecta cientos de paquetes

El 4 de agosto de 2026, un atacante se hizo con el control de la cuenta de GitHub del responsable del mantenimiento de «keyv», una biblioteca de almacenamiento en caché de clave-valor con aproximadamente cientos de millones de descargas semanales en npm, e inyectó un gusano diseñado para robar credenciales en toda la familia de paquetes del responsable, incluidos «cacheable», «flat-cache», «file-entry-cache» y «cache-manager». Conocido como ChainDrop, se propagó a cientos de paquetes adicionales con más de dos mil millones de instalaciones mensuales en total.

Lo que lo hace peligroso no es el número de descargas, sino cómo se ganó la confianza el código malicioso. El atacante lo publicó a través del propio proceso de lanzamiento automatizado del proyecto, por lo que las versiones contaminadas contaban con una procedencia válida: una prueba firmada de que el paquete había sido compilado por el proceso oficial a partir del código fuente auténtico. Esa prueba está pensada para ser una señal de seguridad. En este caso era auténtica, porque el propio proceso se había visto comprometido. Para un desarrollador, o para una herramienta de seguridad que comprobara la firma, la versión maliciosa parecía completamente auténtica.

ChainDrop es la última oleada de una campaña que los investigadores llevan siguiendo desde septiembre de 2025: Shai-Hulud 1.0 (septiembre de 2025), 2.0 (noviembre de 2025) y Mini Shai-Hulud, cuarta oleada (mayo de 2026). Cada una de ellas ha ido ganando intensidad, y las variantes posteriores han incorporado una propagación más agresiva y vulnerabilidades más amplias en la cadena de suministro.

• Fecha: «keyv@6.0.0» es la fecha de inicio confirmada, publicada el 4 de agosto de 2026.

• Punto de entrada: La intrusión comenzó con el acceso no autorizado a la cuenta de GitHub de un responsable del mantenimiento, y la versión maliciosa pasó por el proceso de publicación legítimo del proyecto.

• Magnitud: Las cifras varían según el servicio de seguimiento, pero todos los informes coinciden en que se trató de un incidente de gran envergadura en la cadena de suministro de npm. StepSecurity informó inicialmente de 435 paquetes y 1.557 versiones, mientras que Aikido y otros informes posteriores elevaron el total, con algunas estimaciones que superaban los 1.300 paquetes y rondaban los 2.000 millones de descargas mensuales.

• Carga útil: Existe una ruta de preinstalación que utiliza el archivo setup.mjs, el cual descarga Bun y ejecuta una gran carga útil ofuscada destinada a robar credenciales.

• Atribución: Los investigadores lo clasifican dentro de la familia de malware Shai-Hulud.

Lo que hace que ChainDrop resulte especialmente preocupante es que no se valió de un exploit llamativo ni de una página de descargas falsa. En cambio, se aprovechó de la cadena de suministro de software habitual: el mismo proceso de publicación e instalación de paquetes que utilizan millones de desarrolladores.

En la práctica, esto significa que un paquete puede parecer legítimo, pero contener de forma oculta código malicioso que se activa durante la instalación. Los equipos de seguridad afirman que el malware se diseñó para robar información confidencial de los equipos de los desarrolladores y de los sistemas de CI/CD, incluyendo tokens de GitHub, credenciales de npm, claves de AWS, secretos de Kubernetes y otros datos de acceso.

El riesgo general no se limita a los desarrolladores. Cualquier organización que utilice los paquetes afectados puede verse afectada de forma indirecta a través de los sistemas de compilación, las dependencias y los procesos automatizados de lanzamiento.

ChainDrop nos recuerda que las dependencias de código abierto suponen un riesgo empresarial, y no solo una preocupación para los desarrolladores.

Para cualquier organización que utilice JavaScript y Node.js, ChainDrop nos recuerda que las dependencias de código abierto suponen un riesgo empresarial, y no solo una preocupación para los desarrolladores.

Un paquete comprometido puede heredarse indirectamente a través de las dependencias y los sistemas de compilación, y puede dar lugar al robo de credenciales, al acceso no autorizado a la infraestructura en la nube y a la rotación de secretos y la respuesta a incidentes a gran escala. Cuando la integridad del software, el control de acceso y el riesgo de terceros forman parte de tu entorno de control —como ocurre en el marco de PCI DSS, DORA, NIS2 y CMMC—, esa exposición recae directamente también en el cumplimiento normativo y la gobernanza.

Si has instalado un paquete afectado a partir del 4 de agosto de 2026:

• Analiza tus dependencias: genera una SBOM y compara las dependencias con versiones que se sabe que son maliciosas

• Imagen antes de la revocación: Imagen de los sistemas afectados antes de rotar los tokens. El malware está atento a la revocación de credenciales y puede activar un controlador si se realiza la rotación primero.

• Rotar las claves confidenciales expuestas: rotar todas las claves confidenciales accesibles (tokens de npm, PAT de GitHub, claves SSH, credenciales de la nube) y exigir la autenticación de dos factores (MFA)

• Comprobar por versión exacta, no por nombre: buscar la versión exacta resuelta, no el nombre del paquete; las etiquetas del registro se modificaron durante el incidente

• Elimina los hooks a nivel de repositorio: revisa los archivos .claude/settings.json y .vscode/tasks.json, no solo node_modules

• Auditoría de CI/CD: Realiza una auditoría de CI/CD y GitHub Actions para detectar publicaciones inesperadas o nuevos flujos de trabajo

La lección que hay que extraer es que la defensa eficaz contra este tipo de ataques consiste en comprobar el contenido de un componente, en lugar de confiar en su procedencia.