ChainDrop escaló en menos de 24 horas desde el ataque a Keyv reportado ayer hasta cientos de paquetes adicionales de npm; GitHub detalla en su blog los cambios que ya aplicó a npm y a GitHub Actions, un análisis de Microsoft muestra que el robo de tokens de publicación —no los scripts de instalación— explica la velocidad de la propagación, y una encuesta de Omdia difundida por Docker confirma que el robo de credenciales de desarrollador es ya un patrón dominante en los ataques a la cadena de suministro.
El gusano informático que empezó a propagarse el 4 de agosto de 2026 a través de keyv y sus paquetes hermanos escaló, en menos de 24 horas, a una campaña que SecurityWeek bautizó ChainDrop y que ya suma más de 400 paquetes de npm infectados, según su cobertura publicada ese mismo día. Microsoft, en un análisis técnico de su equipo de seguridad publicado el 4 de agosto, documentó el mecanismo: un gancho preinstall malicioso ejecuta un paquete de JavaScript basado en Bun, fuertemente ofuscado, que busca en la máquina del desarrollador y en los entornos de integración continua credenciales de npm, GitHub, AWS, Kubernetes y HashiCorp Vault, y usa los tokens de npm robados para descargar paquetes legítimos, insertarles el mismo malware, subir la versión y republicarlos, el mecanismo que le permite saltar de un paquete a otro sin intervención humana. El recuento exacto varía según quién lo mida: mientras SecurityWeek confirmaba más de 400 paquetes al cierre del 4 de agosto, Aikido Security —la misma firma que documentó el ataque original a Keyv— elevó la cifra a 868 paquetes en 1.381 versiones, y SafeDep reportó un piso más conservador de 353 versiones verificadas en 79 nombres de paquete, con un techo de 442 versiones bajo monitoreo. Ninguna de las tres cifras es oficial: ni npm ni GitHub han publicado, al cierre de esta edición, un conteo consolidado propio. El malware también instala, según el mismo análisis de Microsoft, archivos de persistencia dentro de las carpetas de configuración de Claude Code y de Visual Studio Code, y cifra los datos robados con AES-256-GCM antes de enviarlos por HTTPS a un dominio del atacante, con GitHub como canal de respaldo si ese dominio falla. La campaña reproduce, a mayor escala, el patrón que esta sección cubrió ayer con el ataque original a Keyv: una cuenta de mantenedor comprometida basta para publicar versiones maliciosas con procedencia («provenance») firmada y válida, porque esa garantía certifica de dónde salió el paquete, no si quien lo publicó tenía autorización real para hacerlo. Microsoft recomienda, en su propio análisis, actualizar a npm 12 y activar la opción min-release-age, rotar desde una máquina limpia cualquier credencial de npm, GitHub, AWS o Vault que haya estado expuesta, purgar las cachés locales de npm y yarn, reconstruir los proyectos afectados desde una base de dependencias conocida como segura, y revisar el reforzamiento de los flujos de publicación por OIDC en GitHub Actions. Costa Rica no publica cifras propias de proyectos locales afectados, pero cualquier equipo de desarrollo que instaló dependencias de Node.js entre la tarde del 4 y la mañana del 5 de agosto debería revisar su package-lock.json o pnpm-lock.yaml contra los nombres de paquete que Microsoft y Aikido Security han publicado, y rotar credenciales si encuentra coincidencias.
GitHub publicó, en su blog oficial de seguridad, una entrada titulada «Disrupting supply chain attacks on npm and GitHub Actions» que detalla los cambios que la plataforma ya desplegó en los últimos meses para cortar las técnicas más comunes de ataque a la cadena de suministro, según el propio texto. La publicación llega la misma semana en que ChainDrop, documentado en esta edición, y el ataque a Keyv del 4 de agosto demostraron que esas técnicas —cuentas de mantenedor comprometidas, scripts de instalación automática, tokens de publicación robados— siguen produciendo resultados para los atacantes. El anuncio se suma a una secuencia que GitHub viene publicando desde setiembre de 2025, con entregas adicionales en diciembre de 2025 y marzo de 2026, según la propia entrada. En paralelo, la protección de tiempo mínimo antes de instalar una versión recién publicada —minimumReleaseAge— ya está disponible en los cuatro gestores de paquetes de JavaScript más usados: pnpm la incorporó en setiembre de 2025, Yarn la sumó como npmMinimalAgeGate a mediados de ese mismo mes, Bun la trajo en su versión 1.3 de octubre de 2025, y npm la sumó en su versión 11.10.0, según documentó el blog de seguridad Socket.dev. Ninguna de las cuatro viene activada por defecto con un valor estricto: cada equipo debe configurar cuántos minutos u horas debe esperar una versión nueva antes de instalarse. GitHub no ha anunciado, en esta entrada, una fecha para que alguna de estas protecciones —el bloqueo de scripts, el tiempo mínimo de instalación o el reforzamiento de OIDC— pase de ser una opción que cada proyecto activa a un valor por defecto obligatorio en todo el registro. Costa Rica no publica cifras propias de adopción de estas configuraciones, pero los equipos de plataforma locales que administran pipelines de integración continua pueden revisar hoy mismo si su archivo .npmrc o su configuración de pnpm ya define un minimumReleaseAge, en lugar de asumir que la protección llegó con la sola actualización del gestor de paquetes.
— La entrada, publicada esta semana en el blog de seguridad de GitHub, describe los cambios que la plataforma ya aplicó a npm y a GitHub Actions para frenar campañas como la de Keyv y ChainDrop.
El análisis técnico que Microsoft publicó el 4 de agosto sobre ChainDrop confirma que el malware entra exactamente por la misma vía que npm bloquea por defecto desde el 8 de julio: un gancho preinstall que ejecuta código antes de que el desarrollador revise una sola línea del paquete. La coincidencia expone una grieta en la lectura de esa defensa como solución cerrada, algo que esta sección ya había señalado el 4 de agosto sobre el ataque original a Keyv: el bloqueo de scripts protege al desarrollador que instala un paquete ya comprometido, pero no toca el mecanismo que permite que ese paquete llegue comprometido al registro en primer lugar. Ese mecanismo, según el propio análisis de Microsoft, es el robo de tokens de publicación de npm: con un token válido, el atacante descarga un paquete legítimo, le inserta el gancho preinstall malicioso, sube el número de versión y republica directamente en el registro de npm, una operación que ocurre del lado del registro, no en la máquina de cada desarrollador, y que ninguna política local de bloqueo de scripts puede anticipar antes de que la versión maliciosa quede publicada. «Un solo token robado puede producir versiones parcheadas maliciosas en todos los paquetes disponibles para ese publicador», señala el equipo de seguridad de Microsoft en su análisis, una descripción que encaja con una campaña que saltó de cuatro paquetes el 4 de agosto a cientos más en menos de un día. Ni Microsoft ni GitHub han publicado, al cierre de esta edición, qué proporción de las instalaciones afectadas corría ya npm 12 con el bloqueo de scripts activo por defecto y aun así resultó comprometida —por ejecutar el proyecto con una versión anterior del cliente, por tener el paquete específico ya aprobado en su lista de allowScripts, o por otra vía que esta sección no pudo confirmar— frente a cuántas simplemente no habían actualizado. Esa falta de datos es, en sí misma, la pregunta que esta sección viene señalando desde ayer: una defensa que depende de que cada proyecto la haya adoptado no dice nada sobre el tamaño real de su cobertura. Costa Rica no registra víctimas propias conocidas de ChainDrop al cierre de esta edición, pero cualquier proyecto de Node.js con dependencias transitivas de los paquetes afectados corre el mismo riesgo estructural, más allá de qué versión de npm use, mientras el mantenedor cuya cuenta fue comprometida siga teniendo permisos de publicación sobre esos paquetes.
Un solo token robado puede producir versiones parcheadas maliciosas en todos los paquetes disponibles para ese publicador.
Docker publicó el 4 de agosto de 2026, en su blog oficial, un resumen de una encuesta de la firma de análisis Omdia realizada en febrero de 2026 y publicada en abril de ese año bajo el título «Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption». El dato central: 77% de las organizaciones encuestadas sufrió al menos un incidente de cadena de suministro de software en los doce meses previos, y 35% reportó específicamente robo de credenciales, secretos o llaves de desarrollador, el mismo tipo de dato que el gusano ChainDrop, documentado en esta misma edición, buscó activamente en máquinas de desarrollo y entornos de integración continua. El propio informe de Omdia describe, según recoge Docker, un patrón que llama campaña Shai-Hulud: ataques automatizados que usan credenciales robadas para inyectar infostealers en paquetes ya establecidos y propagarse por pipelines de integración continua y computadoras de desarrolladores, sin depender de una vulnerabilidad tradicional con identificador CVE, un patrón que la propia encuesta describe como el mismo que ChainDrop reprodujo esta semana. La encuesta también encontró que solo 51% de los equipos calificó las imágenes de contenedor reforzadas como «muy efectivas» para asegurar dependencias de terceros —la única de once categorías de herramientas que una mayoría calificó así—, mientras que 45% de los equipos de seguridad dijo tener una influencia apenas moderada o menor sobre las herramientas que sus propios desarrolladores usan a diario. La información de esta nota proviene únicamente del blog oficial de Docker, que resume el estudio de Omdia sin que El Pisuika haya podido acceder al informe original, de distribución restringida, ni confirmar sus cifras con otra fuente independiente al cierre de esta edición. Costa Rica no aparece desglosada como mercado propio en la encuesta, pero el patrón que describe —equipos que ya toman más de la mitad de su código de fuentes externas u open source, una proporción que Omdia proyecta subirá a 58% en un año— es el mismo que exponen las zonas francas tecnológicas del país, donde bancos y multinacionales dependen de las mismas dependencias públicas de Node.js, Python y Java que ChainDrop y campañas similares llevan meses explotando.
Entre el 3 y el 5 de agosto, N-able, Keyv, pnpm y ChainDrop confirmaron que la cadena de suministro del desarrollo de software sigue siendo el blanco más repetido de agosto, según Microsoft y Docker.
Esta semana, El Pisuika documentó cuatro desarrollos de seguridad en la cadena de suministro de herramientas de desarrollo: el 3 de agosto, N-able reconoció que su primer parche para N-central no bastó frente a una falla ya explotada activamente; el 4 de agosto, un ataque comprometió keyv y sus paquetes hermanos mientras pnpm corregía por separado una falla de sustitución de paquetes entre registries; y el 4 y 5 de agosto, esa misma campaña escaló a lo que investigadores llamaron ChainDrop, con cifras que van de 400 a 868 paquetes de npm infectados según quién los cuente, de acuerdo con SecurityWeek y Aikido Security. Una encuesta de Omdia difundida por Docker el mismo 4 de agosto sitúa este patrón en un marco más amplio: 77% de las organizaciones sufrió algún incidente de cadena de suministro en el último año, y el robo de credenciales de desarrollador aparece entre los vectores más reportados. El análisis técnico de Microsoft sobre ChainDrop ofrece una explicación estructural de por qué estos episodios se repiten pese a las nuevas defensas: un solo token de publicación robado alcanza para comprometer todos los paquetes de un mantenedor, un vector que ninguna política local de bloqueo de scripts de instalación puede anticipar. Para equipos de desarrollo en Costa Rica, la lista de tareas de esta semana creció: confirmar si algún proyecto instaló las versiones comprometidas de keyv, cacheable, flat-cache o file-entry-cache, o cualquiera de los más de 400 paquetes que ChainDrop afectó; actualizar a pnpm 11.20.0 si el proyecto usa registries con nombre; y rotar credenciales de npm, GitHub, AWS o Vault en cualquier máquina que haya instalado dependencias de Node.js entre el 3 y el 5 de agosto sin la protección de min-release-age activa.