El gusano npm Keyv es un ejemplo reciente y preocupante de cómo un ataque de cadena de suministro puede pasar de un paquete concreto a un ecosistema mucho más amplio. Según análisis de seguridad, el incidente comenzó con una versión específica y terminó contaminando cientos de paquetes publicados en el registro de npm durante el 4 de agosto de 2026.
Lo más delicado es la forma de ejecución: el malware se apoya en scripts de instalación que pueden activarse en entornos de desarrollo y en sistemas de integración continua (CI). Además, existen rutas adicionales vinculadas a configuraciones del editor que pueden disparar el payload cuando el usuario confía en el espacio de trabajo.
Cómo se propagó el gusano npm Keyv en npm
La primera aparición del código malicioso se asocia a keyv@6.0.0. A partir de ahí, el problema dejó de limitarse a los espacios relacionados con Keyv y Cacheable y se extendió a cientos de paquetes distribuidos entre múltiples organizaciones.
Los recuentos de alcance varían entre investigadores, en parte porque cambian las etiquetas “latest” en el registro y porque no existe, al cierre de los reportes, una lista pública completa que permita reproducir el mapeo final paquete por paquete. Aun así, se reportaron cientos de artefactos maliciosos:
- SafeDep verificó 353 versiones en 79 nombres de paquete.
- Su monitorización más amplia estimó un pie de huella de 442 versiones en 353 nombres.
- Aikido comunicó, posteriormente, 868 paquetes con 1.381 versiones (según su propio conteo).
Es importante entender esta diferencia: los totales indican versiones y artefactos comprometidos, no necesariamente cuántas máquinas los instalaron o ejecutaron.
El mecanismo del ataque: scripts de preinstalación y entorno CI
El gusano npm Keyv utiliza un script de preinstall para lanzar un conjunto de código orientado a robar información. El objetivo no se limita al equipo de un desarrollador: también puede activarse dentro de entornos de CI donde se automatiza el proceso de instalación.
De acuerdo con el análisis, el payload es capaz de recopilar datos del repositorio y del registro de paquetes, además de material relacionado con cuentas y credenciales. Entre los tipos de información mencionados están elementos de cloud y claves privadas, así como materiales asociados a sistemas como Vault y Kubernetes.
Luego, el atacante puede aprovechar accesos existentes en npm para continuar intoxicando otros paquetes. En otras palabras, el malware no solo “infecta”: también puede facilitar la propagación mediante publicación con identidad robada o reutilizada.
Hooks en Claude Code y VS Code: ejecución tras confiar en la carpeta
Además del camino clásico vía scripts de instalación, el repositorio involucrado conservó configuraciones que actúan como ganchos para Claude Code y Visual Studio Code (VS Code).
En el caso de Claude Code, el archivo .claude/settings.json incluye un hook de SessionStart que llama a .vscode/setup.mjs. Para VS Code, el archivo .vscode/tasks.json contiene una tarea de Environment Setup con un comportamiento de runOn: folderOpen, la cual ejecuta .claude/setup.mjs.
Esto crea una ruta de ejecución desde un repositorio ya comprobado en el equipo del usuario. Sin embargo, no necesariamente se dispara en todos los contextos: depende del nivel de confianza del workspace y de cómo el editor aplique políticas por defecto.
Qué dicen las políticas de confianza
Se señaló que VS Code bloquea tareas automáticas en workspaces no confiables y suele pedir confirmación antes de ejecutar. Por su parte, Claude Code aplica la confianza al tratar la configuración del proyecto suministrada por el propio repositorio. En el momento analizado, esos archivos permanecían presentes en la rama principal.
Por qué las rotaciones tempranas pueden ser un riesgo
Una parte del payload instala un mecanismo asociado a revocar tokens o “vigilar” su revocación. El disparador es la revocación; esto vuelve especialmente importante el orden de respuesta ante incidentes.
Según las recomendaciones de SafeDep, si se rotan primero las credenciales (sin retirar antes el componente de revocación), existe la posibilidad de que el atacante logre ejecutar un manejador local suministrado por él mismo. Por ello, se sugiere quitar el “watcher” de revocación del malware antes de iniciar la rotación de tokens y llaves expuestas.
npm 12, scripts de ciclo de vida y clientes antiguos
El nivel de exposición no es igual para todos los usuarios. Se indicó que npm 12 bloquea de forma predeterminada scripts de dependencias no aprobadas en etapas del ciclo de vida. No obstante, rutas alternativas siguen siendo peligrosas:
- Clientes npm más antiguos.
- Otros métodos de instalación que permitan la ejecución de lifecycle scripts.
En la práctica, si tu entorno acepta scripts de dependencias sin las restricciones modernas, el gusano npm Keyv tiene más oportunidades de ejecutarse al instalar paquetes afectados.
La primera versión maliciosa y su estructura
El lanzamiento confirmado como malicioso fue keyv@6.0.0. Esta versión añadió un archivo y un comando para ejecutar código durante el proceso de instalación:
- Incorporó node setup.mjs como preinstall.
- Incluyó setup.mjs y Math_Symbol.js para publicación.
- Dejó intacto el código compilado de la librería en sí.
En el análisis se describe además una etapa de comprobación: el script verifica si existe Bun y, si es necesario, descarga desde las releases oficiales del GitHub del runtime la versión 1.3.13. Luego transfiere un bloque de datos (un bundle compilado) antes de pasar a la lógica final.
Qué roba el payload (según el análisis) y cómo modifica el ecosistema
El informe de SafeDep sobre el payload indica que el bundle busca material relacionado con GitHub, npm, proveedores de cloud, Vault, Kubernetes, bases de datos y secretos de llaves privadas. También menciona la lectura de memoria del runner de GitHub Actions.
Además, el payload contempla infraestructura para publicar en npm, y Socket habría identificado código adicional orientado a modificar, versionar y volver a publicar paquetes usando una identidad npm comprometida.
Con todo, el análisis también señala límites: no se pudo recuperar con certeza cuál fue la función iniciadora ni determinar si la propagación dependió de una sola identidad robada o de credenciales comprometidas por separado. En consecuencia, aunque el alcance es grande, todavía no se puede cuantificar el número exacto de cuentas comprometidas.
“latest” cambia rápido: por qué no basta con mirar etiquetas
Una de las razones por las que la evaluación del impacto es compleja es el comportamiento del registro. Se observó que las páginas de paquetes mostraban, al menos para algunos nombres, que releases anteriores volvían a aparecer como latest tras el paso del tiempo posterior al incidente.
Entre los ejemplos mencionados estaban keyv@5.6.0, flat-cache@6.1.23 y cache-manager@7.2.9. Pero como el mapeo completo no se pudo reproducir de manera automática con una lista pública cerrada, la recomendación operativa es clara:
Para determinar exposición, revisa nombres de paquete, versiones resueltas y lockfiles en lugar de confiar en un caché de etiquetas “currentes”.
Proveniencia y firmas: el “OK” de la cadena no prueba que el contenido fuera seguro
En el caso del repositorio, el release malicioso contaba con proveniencia válida (incluyendo OIDC y SLSA) porque pasó por un flujo legítimo de GitHub Actions. Esto certifica el proceso de construcción y firmado, pero no garantiza que el contenido de entrada fuera seguro.
En otras palabras: incluso cuando el pipeline de CI y las atestaciones son correctas, eso no excluye que la fuente o el material que terminó en el artefacto estuviera comprometido.
También se menciona que el commit que colocó los hooks mostraba un distintivo de verificación y atribuía la autoría a github-actions[bot]. La verificación valida la firma del commit, pero no aclara por sí sola quién controlaba la credencial que envió esa firma.
Qué hacer si tu entorno ejecutó versiones afectadas
El consejo general es tratar cualquier estación o runner que haya ejecutado una versión comprometida como potencialmente expuesto. Como el malware puede recolectar credenciales, no basta con “actualizar y listo”.
Enfoque recomendado (basado en lo que se describe en los análisis):
- Revisa con precisión qué versiones fueron instaladas usando lockfiles y resoluciones exactas.
- Si encontraste indicios de ejecución, actúa como si existiera robo de credenciales.
- Retira el watcher de revocación del malware antes de rotar tokens y llaves, para evitar disparar manejadores locales.
- Considera también rutas de ejecución desde configuración del editor si trabajaste con repositorios durante el periodo de exposición.
Además, dado que el ecosistema cambió (algunos paquetes relacionados permanecieron limpios y parte del conjunto completo no está completamente mapeado públicamente), un bloqueo a nivel de namespace podría dejar huecos: puede tanto omitir versiones envenenadas como marcar lanzamientos que no están comprometidos.
Señales de familias de malware y ausencia de atribución pública
Los reportes mencionan que el mismo patrón de hooks y el uso de setup.mjs y la descarga de Bun 1.3.13 se documentó en una filtración previa en otro paquete de PyPI (en abril) relacionada con el proyecto Lightning. Aikido también sitúa la actividad de agosto dentro de una familia de malware llamada Shai-Hulud.
Esto sugiere conexión a nivel de familia o técnicas compartidas, pero no identifica con certeza el actor detrás del ataque. No se encontró, al cierre de los reportes, un comunicado público del maintainer, npm o GitHub que detallara la situación o confirmara una atribución.
Conclusión
El gusano npm Keyv demuestra cómo un ataque de supply-chain puede combinar ejecución por scripts de instalación, recolección de secretos y rutas de disparo desde configuraciones de editores. Aunque haya atestaciones y firmas correctas en la canalización de CI, la seguridad real depende de que el contenido de entrada sea confiable.
Si dependes de paquetes npm en desarrollo o en CI, la prioridad es identificar las versiones exactas que se resolvieron y se instalaron, y tratar cualquier posible ejecución como una exposición de credenciales. Con evidencia incompleta y etiquetas que cambian, solo el análisis con nombres, versiones y lockfiles te dará una visión fiable del riesgo.
Fuente: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html
