Gusano en npm: el ataque a keyv y qué debe revisar quien encarga software

En resumen

• Qué pasó: el 4 de agosto de 2026, según Wiz, Socket y Aikido, alguien tomó el control de la cuenta de GitHub del responsable de keyv, una librería de JavaScript muy usada, y publicó versiones con código malicioso. Ese código roba credenciales de quien lo instala y las usa para contaminar otros paquetes, como un gusano.
• Cuánto creció: el recuento cambia según quién cuente y cuándo: de más de 400 a 452 paquetes, y de más de 1.300 a 2.251 versiones envenenadas (ver tabla). Aikido (más de 2.000 millones de instalaciones mensuales) y el organismo de ciberseguridad de Singapur (2.000 millones de descargas mensuales) dan una cifra parecida para el conjunto de paquetes afectados: es el uso mensual de esos paquetes, no una cuenta de equipos infectados.
• Por qué importa: aunque tu empresa no use keyv, tu software está armado con piezas ajenas, y una pieza contaminada puede llegar a quienes la usan, incluso sin que lo sepan.
• Qué hacer: pedirle a quien desarrolla tu software que fije versiones, limite los scripts de instalación, proteja las claves de publicación y use doble verificación en sus cuentas.

Datos verificados al 24 de octubre de 2026.

Qué pasó

keyv es una librería de JavaScript para guardar datos del tipo clave-valor: una pieza que muchos programas usan sin que nadie lo note. Según Elastic, en su nota del 6 de agosto de 2026, recibió más de 600 millones de descargas en el último mes. El 4 de agosto de 2026, según Socket y Snyk, la versión keyv@6.0.0 se publicó a las 09:35 UTC (06:35 en Argentina) y fue la primera con el código malicioso. Snyk, al revisar los paquetes publicados por esa cuenta, identificó 11 versiones maliciosas; esa cifra no incluye el contagio posterior.

Según Aikido, los atacantes tomaron la cuenta de GitHub del responsable del proyecto, subieron archivos maliciosos directamente a la rama principal y publicaron de inmediato una versión nueva. Como la publicación salió por los mecanismos automáticos legítimos de GitHub, las versiones envenenadas llevaban una firma de procedencia válida.

Después se propagó. Según Aikido, tras el compromiso inicial se observaron más de 400 paquetes infectados por contagio entre responsables de proyectos, y lista como ejemplos paquetes publicados con los nombres de Deliveroo, Picsart y Qlik, sin detallar el impacto en cada una. Aikido, Elastic, Wiz, Orca, Integrity360 y el organismo de Singapur relacionan este gusano con la familia de malware llamada Shai-Hulud, y Elastic e Integrity360 lo llaman ChainDrop. Son nombres del malware, no de quien lo usa.

Quién cuenta	Qué cuenta	Cifra	Fecha de la nota
Wiz	Paquetes distintos alcanzados por el gusano	Más de 400	4 de agosto
Aikido (actualización)	Paquetes y versiones comprometidos	Al menos 444 paquetes y 1.381 versiones	5 de agosto
Integrity360, citando a Socket	Versiones envenenadas y paquetes únicos	2.251 versiones y 452 paquetes	5 de agosto
Organismo de ciberseguridad de Singapur (CSA)	Versiones comprometidas en el registro npm	Más de 1.300 versiones	6 de agosto

Las cifras difieren, probablemente por el momento del recuento y por lo que se cuenta (paquetes o versiones); las fuentes no lo aclaran. En lo esencial, las fuentes revisadas describen el mismo mecanismo.

Cómo ocurrió, explicado sin tecnicismos

Piensa en una cocina. Tu empresa es el restaurante y el software que encargas es el menú. Para cocinar, el restaurante no fabrica todo: compra ingredientes (las librerías) a proveedores, que a su vez los compran a otros. keyv es un ingrediente básico que aparece en una enorme cantidad de recetas, muchas veces de forma indirecta. Según Socket, una cadena habitual va de eslint a file-entry-cache, a flat-cache y a keyv, así que la mayoría de los afectados nunca instaló ninguna de esas piezas directamente.

Según las fuentes, los atacantes entraron al depósito del proveedor (la cuenta del responsable) y contaminaron el ingrediente sin tocar la etiqueta. Y la etiqueta de "procedencia verificada" decía la verdad: el ingrediente salió de la fábrica del proveedor, pero ya estaba contaminado cuando se empaquetó. Socket lo resume así: la procedencia certifica la integridad de la compilación, no la del código de origen.

Cuando alguien instala el paquete, un script se ejecuta solo y busca las llaves de la despensa. Según Orca, apunta a credenciales en la nube, tokens de GitHub, claves SSH y secretos de integración continua, entre otros. Con la llave de publicación de un desarrollador, el gusano republica versiones contaminadas de los otros paquetes que esa persona administra, y así salta de una cocina a otra. Según Elastic, solo se propaga con llaves de npm que tengan permiso de escritura y puedan publicar sin segundo factor de autenticación.

También intenta quedarse. Según Socket, deja archivos de arranque en carpetas de editores y asistentes de programación, pensados para alcanzar a quienes clonan el proyecto. Y Socket, Snyk e Integrity360 describen un vigilante que reacciona cuando se revocan las credenciales robadas: por eso piden retirar el código malicioso antes de cambiar las claves.

Qué se sabe y qué todavía no

• Versiones afectadas. El organismo de Singapur lista, entre otras, keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1 y cache-manager 7.2.10, y remite a Socket para la lista completa.
• Velocidad de detección. Según Socket, en esta campaña los paquetes afectados se detectaron, en promedio, 5 minutos y 18 segundos después de su publicación.
• Cuidado con las etiquetas. Según Integrity360, el 4 de agosto se restauraron versiones limpias como la versión actual (latest) de al menos nueve paquetes principales: por eso la exposición se verifica con las versiones exactas del archivo de bloqueo, no con las etiquetas de hoy.

Lo que todavía no se sabe:

• Cómo se comprometió la cuenta. Las notas revisadas (Wiz, Socket, Snyk, Aikido, Integrity360, Orca y el organismo de Singapur) no explican cómo se obtuvo el acceso. Snyk es la más prudente: dice que la evidencia respalda el compromiso de una cuenta, una credencial, una sesión o una vía de publicación, y pide tratar al responsable del proyecto como víctima del incidente.
• El alcance real. Snyk dice que, al momento de su nota, no había un recuento público verificado de ejecuciones exitosas ni de credenciales robadas, y aclara que las cifras de descargas miden el alcance del ecosistema, no equipos comprometidos. Aikido contó, al momento de su nota, unos 1.300 repositorios públicos con la descripción que usa el malware para guardar datos robados cifrados: es un indicio, no un recuento verificado de víctimas.
• Quién está detrás. Las fuentes no coinciden: Orca lo atribuye a un grupo, Integrity360 aclara que esa atribución no está confirmada y Socket dice que su muestra no traía marcas que la vinculen con una campaña con nombre. Aquí no se toma partido.
• Un CVE. Según Integrity360, al momento de su nota no se había asignado ninguno.
• Novedades. Las notas revisadas son del 4 al 6 de agosto y no se encontró un balance final posterior.

Qué lecciones deja para una pyme o un profesional de Córdoba

No hace falta programar para exigir esto a quien desarrolla tu software. Siete acciones, todas comprobables:

1. Pregunta si tu software usa estas piezas y pide la respuesta por escrito. Quien lo desarrolla puede buscar las versiones afectadas en el archivo de bloqueo (lockfile). Integrity360 pide mirar las versiones exactas ahí y no las etiquetas actuales del registro.
2. Exige versiones fijas y el lockfile guardado en el repositorio. Integrity360 pide guardar los lockfiles en el control de versiones y fijar versiones exactas; Socket recomienda versiones exactas bloqueadas por hash de integridad y que ningún rango ni actualización automática traiga una versión nueva mientras la cuenta siga comprometida. Comprobable: el archivo existe y las instalaciones salen de él.
3. No adoptes de inmediato las versiones recién publicadas. Elastic recomienda un período de espera antes de que los sistemas de compilación adopten versiones nuevas, para dar tiempo a la comunidad a detectar compromisos antes de que lleguen a ellos.
4. Limita los scripts que se ejecutan al instalar. Según Snyk, desactivar esos scripts limita esta vía de ejecución, y conviene mantener una lista corta de excepciones en lugar de habilitarlos en todo. Este ataque arrancaba con uno de ellos.
5. Pide doble verificación en todas las cuentas de desarrollo (GitHub, npm, nube) y evita llaves que publican sin ella. Elastic recomienda activarla en todas las cuentas de npm y evitar tokens de automatización que la omitan. Comprobable: lista de cuentas con doble verificación y de llaves con sus permisos.
6. Reduce los secretos en las computadoras de trabajo. Según Aikido, el código buscaba archivos .env, claves SSH y estado de Terraform, entre otros. Criterio general, no una recomendación de Aikido: menos secretos sueltos, con permisos mínimos y vencimiento, es menos para robar. Comprobable: inventario de claves con fecha y responsable.
7. Define de antemano qué se hace si se instaló una versión afectada. El organismo de Singapur indica tratar esos sistemas como potencialmente comprometidos y reconstruirlos. Integrity360 pide retirar primero el código malicioso y recién después rotar credenciales: el orden importa. Snyk pide coordinar la remoción con personal de respuesta a incidentes, por eso conviene contar con ayuda especializada.

Es otra cara de lo que mostró el caso de PHP2Shell: el software se apoya en piezas ajenas y conviene saber quién las vigila. Para ver el panorama de tu empresa, está la guía de ciberseguridad para pymes en Argentina. Si quieres que alguien revise contigo cómo está armado tu software o tus cuentas de desarrollo, el equipo de Julián Bagilet hace revisión y refuerzo de seguridad: puedes ver cómo trabaja el estudio en el servicio de seguridad informática.

Preguntas frecuentes

¿Qué es la cadena de suministro de software?

Todo lo que entra en tu software y no escribió tu equipo: librerías, herramientas y las cuentas con las que se publican. Si una de esas piezas se contamina, la contaminación viaja con ella. El organismo de Singapur describe este caso como un ataque a la cadena de suministro de software con versiones maliciosas de Keyv y de paquetes relacionados.

Si mi software usa keyv, ¿estoy comprometido?

No necesariamente. Según Orca, hay que tratar como potencialmente comprometido a todo desarrollador, sistema de compilación o corredor de CI/CD que instaló o actualizó un paquete afectado después de publicadas las versiones maliciosas el 4 de agosto de 2026. Lo que importa es qué versión exacta se instaló y cuándo: pídele a tu proveedor que lo verifique en el lockfile.

¿Una firma de procedencia garantiza que un paquete es seguro?

No. Según Snyk, la procedencia puede certificar fielmente una compilación cuyo código de origen ya estaba comprometido. Es útil como dato sobre dónde se armó el paquete, no como garantía de que su contenido sea limpio.

¿Qué hago si mi proveedor instaló una versión afectada?

No cambies claves a ciegas. Según Integrity360, no se deben rotar tokens antes de retirar el código malicioso, porque el malware instala un vigilante que reacciona a eso. Según Snyk, hay que aislar el equipo, buscar y desactivar la persistencia y recién entonces rotar las credenciales desde un sistema limpio. Pídele eso a tu proveedor.

Fuentes

• Wiz Research, "keyv and cacheable npm Package Hijacked in Supply Chain Attack", 04/08/2026. wiz.io
• Socket Research Team, "Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack", 04/08/2026. socket.dev
• Snyk, "Inside the keyv npm Compromise: preinstall Malware, Trusted Provenance, and IDE Hooks", 04/08/2026. snyk.io
• Aikido Security, "Keyv and friends compromised in npm supply chain attack", 04/08/2026 (actualizado el 05/08). aikido.dev
• Elastic Security Labs, "Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packages", 06/08/2026. elastic.co
• Integrity360, "ChainDrop: The Keyv and Cacheable npm Supply Chain Attack", 05/08/2026. integrity360.com
• Orca Security, "Compromised keyv Maintainer Account Triggers Massive npm Supply Chain Attack", 05/08/2026. orca.security
• Cyber Security Agency of Singapore, "Ongoing npm Supply Chain Attack Affecting Keyv and Related Packages (Shai-Hulud Worm)", 06/08/2026. csa.gov.sg