Una cuenta de GitHub comprometida publica malware que roba credenciales en keyv, cacheable, flat-cache y file-entry-cache; npm ya retiró las cuatro versiones del registro, pnpm 11.20.0 corrige una falla que permitía sustituir paquetes entre registries con nombre, Next.js, Storybook y Supabase publican actualizaciones el mismo día, y la política de scripts bloqueados por defecto que npm activó en julio no impidió el ataque.
La campaña, detectada la madrugada del 4 de agosto, publicó versiones troyanizadas de keyv, cacheable, flat-cache y file-entry-cache con procedencia firmada por GitHub Actions; npm ya retiró las cuatro versiones del registro público.
Un atacante comprometió, la madrugada del 4 de agosto de 2026, la cuenta de GitHub del mantenedor de keyv —una librería de almacenamiento clave-valor con 127 millones de descargas semanales en npm— y la usó para publicar una versión troyanizada de la 6.0.0, además de nuevas versiones maliciosas de cacheable, flat-cache y file-entry-cache, tres utilidades de caché que el mismo mantenedor publica, según documentó la firma de seguridad Aikido Security. Cada paquete de la familia recibió dos archivos nuevos, setup.mjs y Math_Symbol.js, y una entrada preinstall en su package.json que ejecuta ese código automáticamente durante la instalación, antes de que el desarrollador revise una sola línea del paquete. El código publicado el 4 de agosto roba tokens de autenticación del registro de npm guardados en el archivo .npmrc, tokens de GitHub CLI —incluidos PAT clásicos, tokens de sesión y tokens OIDC—, llaves de acceso y tokens de sesión de AWS almacenados en ~/.aws/credentials, y tokens de cliente de HashiCorp Vault leídos de la variable de entorno VAULT_TOKEN, según el análisis técnico de Aikido Security. Las cuatro versiones maliciosas llevaban procedencia («provenance») válida, firmada automáticamente por GitHub Actions al publicarse desde el repositorio oficial —la misma garantía que npm promueve desde 2023 como defensa contra paquetes falsificados, y que aquí no sirvió de nada porque el repositorio legítimo fue el que quedó comprometido, no uno falso. El registro público de npm, revisado por El Pisuika al cierre de esta edición, confirma que las cuatro versiones —keyv 6.0.0, cacheable 2.5.1, flat-cache 6.1.24 y file-entry-cache 11.1.6— ya no figuran entre las versiones publicadas del paquete, y que el alias latest de los cuatro volvió a apuntar a las versiones anteriores al ataque. Aikido Security no ha publicado una cifra de cuántos proyectos llegaron a instalar alguna de las cuatro versiones maliciosas antes de su retiro; la información sobre la mecánica del ataque proviene únicamente de esa firma, sin confirmación cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de proyectos locales que dependan de keyv o de sus paquetes hermanos, pero las cuatro utilidades son dependencias transitivas comunes en aplicaciones de Node.js construidas con frameworks como Express o NestJS; los equipos ticos que instalaron dependencias entre la madrugada y la media mañana del 4 de agosto deberían revisar su package-lock.json o pnpm-lock.yaml por esas cuatro versiones exactas y rotar cualquier credencial de npm, GitHub, AWS o Vault presente en esa máquina.
El proyecto pnpm publicó el 3 de agosto de 2026 la versión 11.20.0 de su gestor de paquetes, con una corrección de seguridad para los proyectos que usan named registries —la función que permite mezclar un registry privado corporativo con el registro público de npm dentro del mismo proyecto—, según el registro oficial de cambios (CHANGELOG) publicado en el repositorio del propio pnpm. Desde la versión 11.1.0 el lockfile de pnpm guardaba cada dependencia bajo la clave nombre@versión, sin ningún marcador de cuál registry la había resuelto; si dos registries distintos publicaban un paquete con el mismo nombre y la misma versión, ambos colapsaban en una sola entrada y el primero en resolverse decidía qué tarball recibían todos los consumidores del proyecto. El propio equipo de pnpm describe el problema, en su documentación oficial, como «un riesgo de sustitución de paquete»: uno que un equipo espera de su registry privado podía terminar instalándose, sin ninguna advertencia, desde un registry distinto que publicara el mismo nombre y versión —el mismo patrón, llamado dependency confusion, que ya se ha usado para comprometer cadenas de suministro corporativas en el pasado. La versión 11.20.0 corrige esto registrando cada paquete resuelto desde un registry con nombre bajo una clave calificada (nombre@registry:versión), lo que el propio pnpm califica como un cambio «semibreaking»: la primera instalación no congelada después de actualizar reescribe esas entradas en el lockfile, y ese diff hay que revisarlo y aceptarlo a mano, según el mismo documento. pnpm no ha asignado, en su changelog, un identificador CVE o GHSA a esta falla, y la información sobre el hueco proviene únicamente del propio proyecto, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de equipos locales que usen named registries de pnpm, pero la función es común entre bancos y empresas de zonas francas tecnológicas que combinan paquetes internos con el registro público; esos equipos deberían actualizar a la 11.20.0 y revisar con cuidado el primer diff de lockfile que produzca la nueva versión, en vez de aceptarlo sin mirar por tratarse de «solo un cambio de formato».
Seis proyectos de código abierto de uso amplio en desarrollo web publicaron nuevas versiones el 3 y el 4 de agosto de 2026: Next.js llegó a la 16.3.0, AWS CDK a la 2.1135.0, Storybook a la 10.5.6, el cliente de JavaScript de Supabase a la 2.112.0, webdriverio a la 9.30.1 y Hono a la 4.13.0, según confirman los registros oficiales de npm de cada paquete. Dos de esos lanzamientos incluyeron trabajo de seguridad concreto: Storybook 10.5.5, publicada el 27 de julio, había subido la versión interna de la librería ws «para corregir avisos de seguridad», según su propio registro de cambios, y webdriverio 9.30.1 incorporó dos correcciones catalogadas como «Fix/deps security overrides» sobre sus dependencias. El resto del lote fue trabajo de mantenimiento ordinario: Storybook 10.5.6 fijó la versión de @testing-library/jest-dom y corrigió un problema de generación de documentación en Vue, el cliente de Supabase movió el rastreo de OpenTelemetry a una ruta opt-in (/tracing) y corrigió tres errores de tipos y de manejo de errores, y webdriverio hizo configurable el tiempo de espera de las respuestas del protocolo WebDriver Bidi, según el registro de cambios de cada proyecto. Ninguno de los seis lanzamientos rompió compatibilidad hacia atrás. La coincidencia de fecha no responde a un anuncio coordinado —cada proyecto sigue su propio calendario— sino al ritmo normal de un ecosistema donde decenas de paquetes de uso masivo se actualizan cada semana, el mismo ritmo que hace más difícil detectar, entre tantas versiones legítimas, la publicación puntual de una versión maliciosa como la de Keyv. Ninguno de los seis proyectos ha anunciado cambios adicionales previstos antes de la próxima ventana de versiones. Costa Rica no publica cifras propias de adopción de estas herramientas, pero Next.js, Storybook y Supabase son opciones comunes entre agencias de desarrollo web y startups ticas, mientras que webdriverio se usa en equipos de aseguramiento de calidad que automatizan pruebas de interfaz; esos equipos pueden actualizar hoy mismo sin revisar código propio, dado que ninguno de los seis lanzamientos exige cambios de compatibilidad.
npm publicó la versión 12.0.0 de su cliente de línea de comandos el 8 de julio de 2026 con un cambio de comportamiento por defecto: los scripts del ciclo de vida de las dependencias —preinstall, install y postinstall, el mecanismo que un paquete usa para ejecutar código automáticamente durante npm install— quedan bloqueados salvo que la política allowScripts del paquete raíz del proyecto los autorice explícitamente, según el registro oficial de cambios del proyecto npm/cli. Un desarrollador que quiera permitirlos debe correr npm install-scripts approve para aprobarlos uno por uno y npm rebuild para ejecutarlos. Esa es, exactamente, la vía que el ataque a Keyv documentado en esta misma edición usó para instalar su malware: una entrada preinstall que ejecuta setup.mjs en el momento de la instalación. La coincidencia no prueba que la protección de npm 12 fallara: cacheable, flat-cache, file-entry-cache y la versión anterior de keyv no traían scripts de instalación, así que un proyecto que ya tuviera esas dependencias con allowScripts habilitado por defecto —o que instalara con una versión de npm anterior a la 12, o con otro gestor de paquetes sin esa misma política, como pnpm o yarn en configuraciones donde el bloqueo no está activo— habría ejecutado igual el código malicioso al actualizar. Ni npm ni Aikido Security, la firma que documentó el ataque, han publicado datos sobre cuántas de las instalaciones afectadas corrían con la protección de npm 12 activa y aun así ejecutaron el script, y cuántas corrían gestores o configuraciones donde la barrera nunca llegó a interponerse. Esa falta de datos es, en sí misma, la pregunta abierta: una defensa por defecto solo protege a los proyectos que ya adoptaron la versión que la trae, y npm no ha dicho qué proporción del ecosistema sigue todavía en la 10 o en la 11.
Los scripts del ciclo de vida de las dependencias ahora están bloqueados por defecto, salvo que la política allowScripts del paquete raíz los permita.
El ataque a Keyv y la corrección de pnpm, ambos de esta semana, se suman a los parches de N-able y GitLab de julio: la cadena de suministro sigue siendo el blanco más repetido.
Esta edición documentó dos desarrollos de seguridad en la cadena de suministro de herramientas de desarrollo: el ataque que infectó keyv, cacheable, flat-cache y file-entry-cache con malware que roba credenciales, y la corrección de pnpm a una falla que permitía sustituir paquetes entre registries con nombre. Ambos se suman a una lista que esta sección viene documentando desde finales de julio: el parche incompleto de N-able para N-central, la campaña ChocoPoC que escondía malware dentro de exploits de prueba falsos, y los trece parches de seguridad que GitLab publicó la semana pasada. El patrón se repite con una variación: los dos casos de esta semana no atacan una aplicación en producción, sino la cadena de herramientas que los propios desarrolladores usan para instalar dependencias —el registro de paquetes en el caso de Keyv, el lockfile en el caso de pnpm. npm ya bloquea por defecto los scripts de instalación desde julio, la defensa más directa contra ataques como el de Keyv, pero esta edición no encontró datos que confirmen cuántas de las instalaciones afectadas corrían esa protección activa. Esa falta de visibilidad —no solo la existencia de la falla— es lo que conecta los desarrollos que esta sección ha cubierto en las últimas dos semanas. Para equipos de desarrollo en Costa Rica, la tarea concreta de esta semana es doble: revisar si algún proyecto instaló keyv, cacheable, flat-cache o file-entry-cache entre la madrugada y la media mañana del 4 de agosto, y actualizar a pnpm 11.20.0 si el proyecto usa registries con nombre, revisando a mano el primer diff de lockfile que produzca.