El martes 4 de agosto de 2026, mientras miles de equipos compilaban su código como cualquier otro día, un gusano entró al registro de npm y se propagó solo. No fue un paquete falso con nombre parecido: fueron versiones nuevas de librerías reales que tu proyecto probablemente ya instala sin que nadie lo haya decidido. Si en tu empresa se desarrolla software, se mantiene un sitio web con proceso de compilación o se trabaja con un proveedor que lo hace, este incidente te toca directamente.

Qué ocurrió el 4 de agosto

De acuerdo con la investigación de Wiz, alrededor de las 09:00 UTC los atacantes tomaron el control de la cuenta de GitHub del mantenedor detrás de keyv y cacheable, dos familias de librerías de caché y almacenamiento clave-valor. A las 09:35 UTC se publicó keyv 6.0.0 con un hook de instalación malicioso. Socket lo detalla así: un script setup.mjs que npm ejecuta antes de terminar la instalación, descarga un runtime independiente, corre una segunda etapa ofuscada, cosecha credenciales de npm, GitHub, AWS y HashiCorp Vault, y con el token robado republica versiones troyanizadas de otros paquetes a los que ese token tiene acceso. Tres minutos después, a las 09:38, el gusano ya había saltado a un paquete de otro mantenedor.

Las cifras que reportan los equipos que siguen la campaña dan la escala del problema:

Cloudsmith contabiliza alrededor de 444 paquetes legítimos afectados y unas 2,236 versiones maliciosas publicadas.
Chainguard advierte que los conteos siguen subiendo y que distintos rastreadores hablan de entre 400 y más de 2,200 paquetes y artefactos, sin una lista verificada y completa.
Aikido cifra a keyv en unos 127 millones de descargas semanales, y menciona que flat-cache y file-entry-cache, del mismo mantenedor, rebasan los 550 millones de descargas mensuales cada uno.
Socket midió un tiempo promedio de detección de 5 minutos y 18 segundos por artefacto publicado: incluso así, el gusano ya estaba dentro de muchas instalaciones.

Por qué te afecta aunque nunca hayas oído esos nombres

Socket describe una cadena típica: eslint depende de file-entry-cache, que depende de flat-cache, que depende de keyv. Es decir, la mayoría de los equipos afectados nunca instaló ninguno de esos paquetes de forma directa: llegaron como dependencias de dependencias. Cualquier aplicación Node, cualquier tablero interno, cualquier sitio corporativo que se compile con herramientas modernas puede tenerlos.

Hay un segundo detalle incómodo. Según Aikido, el atacante subió los archivos maliciosos a la rama principal y luego liberó la versión desde el flujo normal del proyecto, así que los paquetes llegaron a npm con provenance válida firmada por GitHub Actions. Traducido a decisiones de gestión: la firma de origen te dice de dónde vino el código, no que sea confiable.

El detalle que cambia el orden de la respuesta

Aquí está lo que ningún responsable de TI debería pasar por alto. Los investigadores de Socket encontraron, junto al robo de credenciales, un mecanismo de “interruptor de hombre muerto” a nivel de sistema: un servicio disfrazado con un nombre inofensivo, del tipo monitor de validez de tokens de GitHub, que se dispara justamente cuando alguien revoca las credenciales robadas. Rotar contraseñas y llaves es el paso uno de casi todos los manuales; aquí puede ser el detonador. La recomendación de Socket es contundente: primero busca y elimina el mecanismo, después rotas.

Qué hacer esta semana en tu empresa

Revisa el lockfile, no la etiqueta latest. Chainguard insiste en comparar la versión exacta instalada contra el archivo de bloqueo, y en tratar como sospechosa cualquier versión de los paquetes afectados publicada el 4 de agosto de 2026 o después.
Fija versiones limpias. Chainguard reporta que npm restauró, entre otras, keyv 5.6.0, flat-cache 6.1.23 y cache-manager 7.2.9.
Limpia antes de rotar. Busca servicios y tareas programadas recién creadas en las máquinas de desarrollo y en los servidores de compilación, y elimina cualquier resto del script de instalación.
Después, rota todo: tokens de npm, credenciales personales de GitHub, llaves de AWS, secretos de Vault y variables del pipeline de integración continua.
Audita las cuentas de tu organización en GitHub y npm: repositorios creados sin explicación y publicaciones no autorizadas son las señales que describen los investigadores.
Reconstruye en limpio: borra node_modules y cachés, e instala desde cero contra el lockfile verificado.

Cuatro medidas para el próximo golpe

Este tipo de campaña —de la familia del gusano conocido como Shai-Hulud— ya es recurrente, así que conviene tratarla como riesgo operativo permanente y no como emergencia aislada:

Desactiva por omisión la ejecución de scripts de instalación y habilítalos solo para los paquetes que realmente lo necesitan.
Pon una cuarentena a las versiones nuevas: un registro intermedio que retenga de uno a tres días cada publicación antes de que llegue a tus compilaciones.
Exige lockfiles y compilaciones reproducibles en todos los proyectos; en producción, nada de rangos abiertos de versión.
Usa credenciales efímeras en la integración continua y segundo factor obligatorio (de preferencia llaves de acceso) en las cuentas de tu equipo.

Si tu software lo desarrolla un proveedor externo, tienes derecho a pedirle por escrito dos cosas esta misma semana: el inventario de dependencias de tu aplicación y la confirmación de que revisó y rotó credenciales tras este incidente. En EDISAS llevamos 30 años construyendo software para PyMEs y gobierno en Sinaloa, y este tipo de eventos confirma algo simple: la seguridad de tu sistema ya no depende solo de tu código, sino de todo lo que tu código instala sin preguntarte.