La ficha de GitHub Advisory Database sobre crypto-js, con pérdidas superiores a USD 5 millones según Coinspect, abre una edición que también cubre ocho advisorías sobre GitPython y go-git, cuatro fallas en Hono y SvelteKit, dos fallas de memoria en pypdf, el nuevo escaneo de malware de npm y el retiro de Copilot como revisor automático en GitHub Code Quality.
La falla, agregada el 7 de agosto a GitHub Advisory Database, permitió calcular frases de recuperación de monederos cripto y ya provocó pérdidas superiores a USD 5 millones, según la firma Coinspect.
GitHub incorporó el 7 de agosto de 2026 a su Advisory Database la ficha GHSA-rg76-677x-56q9 (CVE-2026-71851), que documenta una falla crítica de entropía insuficiente en crypto-js, biblioteca de cifrado ampliamente usada en JavaScript, con una puntuación CVSS de 9.0 sobre 10. La función CryptoJS.lib.WordArray.random(), presente en todas las versiones anteriores a la 4.0.0, genera números aleatorios con una variante del algoritmo Multiply-With-Carry sembrada con Math.random() en lugar de una fuente criptográficamente segura, según detalla la propia ficha. Una solicitud nominal de 128 o 256 bits de entropía produce, en la práctica, un espacio de búsqueda de apenas 2^39 o 2^47 posibilidades —lo bastante pequeño para enumerarlo con hardware de consumo—, según la misma fuente. GitHub acreditó el hallazgo al investigador identificado como juli. El problema, heredado desde la versión 3.1.2-4 de crypto-js y presente en casi toda la rama 3.x, tiene consecuencias que van más allá de un cifrado débil en abstracto: aplicaciones de monedero (wallet) que usaron esa función como fuente de entropía para generar frases de recuperación BIP39 quedaron expuestas a que un atacante reconstruyera la clave privada correspondiente, según la misma ficha de GitHub, que cita la investigación de la firma de seguridad Coinspect bajo el nombre en clave Ill Bloom. Coinspect documentó pérdidas superiores a USD 5 millones atribuidas a esta falla hasta julio de 2026, una cifra que, al cierre de esta edición, El Pisuika no pudo confirmar con una segunda fuente independiente. La falla también permite falsificar firmas HMAC y evadir autenticaciones que dependan de esa aleatoriedad. crypto-js corrigió el problema de raíz en su versión 4.0.0, publicada hace varios años, pero GitHub recién sumó la ficha a su Advisory Database el 7 de agosto —una demora que se explica, en parte, por el atraso que la propia compañía reconoció este año en el procesamiento de asesorías, con reportes privados que pasaron de unos 550 a más de 3.000 por semana entre enero y mayo de 2026. Costa Rica no registra pérdidas propias conocidas ligadas a esta falla, pero el país alberga un ecosistema creciente de fintech y desarrollo de billeteras cripto en sus zonas francas tecnológicas, cuyos equipos deberían auditar cualquier dependencia heredada de una versión de crypto-js anterior a la 4.0.0.
GitHub Advisory Database sumó, entre el 4 y el 7 de agosto de 2026, ocho fichas de seguridad sobre las dos bibliotecas cliente de Git más usadas fuera de la línea de comandos oficial: seis para GitPython, el enlace de Python a Git, y dos para go-git, su equivalente en Go. Las dos fallas de mayor severidad en GitPython —GHSA-wvpp-8hx9-p66j, con CVSS 8.8, y GHSA-9rj7-rf2p-w77r, con CVSS 7.5— permiten ejecución remota de código: la primera combina un parámetro de una sola letra con la opción split_single_char_options=False para burlar el filtro check_unsafe_options y colar un argumento --upload-pack= hacia git, y la segunda abusa del parámetro --template de Repo.init() para plantar un git hook malicioso que se ejecuta en la siguiente operación. Ambas afectan a GitPython 3.1.57 y versiones anteriores, y quedan corregidas en la 3.1.58, según las respectivas fichas, acreditadas a los investigadores zx (Jace) y BarakSrour. En go-git, la biblioteca que herramientas de integración continua y clientes de escritorio usan para manipular repositorios sin invocar al binario de Git, GitHub documentó dos fallas de salto de directorio (path traversal): GHSA-hc8v-wwc9-vgxm (CVSS 7.1) permite que operaciones de árbol de trabajo sigan enlaces simbólicos y escriban fuera de la ruta prevista —un enlace llamado s que apunta a .git puede usarse para sobrescribir .git/config—, mientras GHSA-qgq7-7hm3-q39j (CVSS 6.3) permite que un nombre de referencia malicioso como refs/heads/../../config escape del directorio de almacenamiento de referencias. Ambas afectan a go-git v5 hasta la 5.19.1 y a la v6 hasta la 6.0.0-alpha.4, y quedan corregidas en 5.19.2 y 6.0.0-alpha.5, según las fichas de GitHub, que acreditan el hallazgo a los investigadores kodareef5, HughLewis20, Saku0512 y Sahana2524. Las ocho fallas comparten un patrón: bibliotecas que decenas de miles de proyectos usan para automatizar Git sin pasar por el binario oficial, donde una validación insuficiente de parámetros o rutas basta para escalar de una operación rutinaria a ejecución de código o filtración de archivos. Ninguna de las ocho fallas fue explotada de forma conocida al cierre de esta edición, según las fichas consultadas; la explotación de las críticas de GitPython además requiere que la aplicación anfitriona reenvíe parámetros controlados por el atacante, una condición que no se cumple en todo software que usa la biblioteca. Costa Rica no publica cifras propias de adopción de GitPython o go-git, pero ambas bibliotecas son comunes en herramientas internas de automatización de equipos de plataforma de empresas de zonas francas tecnológicas del país, que deberían actualizar a las versiones corregidas antes de exponer cualquier flujo que acepte parámetros de Git desde fuentes externas.
Las cuatro fichas, sumadas el 7 de agosto a GitHub Advisory Database, fueron reportadas semanas antes; su publicación conjunta refleja más el atraso de GitHub en revisar asesorías que una ola nueva de fallas.
GitHub Advisory Database publicó el 7 de agosto de 2026 cuatro fichas de seguridad sobre dos frameworks de JavaScript ampliamente usados: tres para Hono, el framework ligero de servidores web, y una para SvelteKit. En Hono, la falla más seria —GHSA-f23p-vx2j-j53r, CVE-2026-71850, CVSS 4.8— describe que la función memo() de su sistema de JSX en servidor cachea el HTML renderizado solo comparando propiedades, sin considerar el contexto de cada solicitud, lo que puede servir contenido de un usuario a otro cuando ambos renderizan el mismo componente con las mismas props; según la ficha, eso puede exponer datos de cuenta, tokens CSRF o contenido según el rol. Las otras dos fallas de Hono corrigen una denegación de servicio por complejidad algorítmica en su middleware de detección de idioma (GHSA-54fx-42gc-7vw4, CVSS 5.3) y una fuga de encabezados de conexión en su ayudante de proxy (GHSA-79qm-7rj5-m7r9, CVSS 3.7). Las tres quedan resueltas en Hono 4.12.34, acreditadas a los investigadores raster0x2a, Yusuke Wada y morgan-coded. SvelteKit, por su parte, corrigió en la versión 2.70.2 una denegación de servicio por expresiones regulares (ReDoS) en la negociación de contenido: un encabezado Accept diseñado a propósito puede agotar la CPU del servidor, según documenta la ficha GHSA-29g2-3rmr-qm68 (CVE-2026-66062, CVSS 5.3), acreditada al investigador que usa el seudónimo Elliott with the longest name on GitHub. Ninguna de las cuatro fallas alcanza severidad crítica ni fue reportada como explotada. Lo que sí llama la atención es el calendario: las fechas de reporte original van del 29 de julio (SvelteKit) al 3 de agosto (dos de las tres de Hono), pero las cuatro aparecieron en el tablero de GitHub el mismo 7 de agosto. Ese patrón no significa que Hono y SvelteKit hayan sufrido una ola repentina de fallas ese día: refleja, sobre todo, cómo GitHub procesa su cola de asesorías represada, un atraso que el propio blog de seguridad de la compañía reconoció este año, con reportes privados que subieron de unos 550 a más de 3.000 por semana entre enero y mayo de 2026, y con procesos de revisión que pasaron de tardar cerca de una semana a varias semanas para buena parte de las fichas. Ni Hono ni SvelteKit respondieron públicamente, en las fuentes consultadas para esta nota, sobre si planean acelerar la divulgación de sus propias fallas en lugar de esperar al calendario de revisión de GitHub. Costa Rica no publica cifras propias de adopción de estos frameworks, pero ambos ganaron tracción entre equipos de frontend y de APIs livianas en startups y zonas francas tecnológicas del país durante 2026, cuyos desarrolladores deberían actualizar a Hono 4.12.34 y SvelteKit 2.70.2 sin asumir que la fecha de publicación de una ficha equivale a la fecha real de la falla.
GitHub Advisory Database publicó, el 6 y el 7 de agosto de 2026, dos fichas de severidad moderada sobre pypdf, la biblioteca de Python más usada para leer y manipular archivos PDF. La primera, GHSA-fp3f-mc75-235c (CVE-2026-71870, CVSS 4.8), describe que un PDF con valores anormalmente grandes en las entradas de fuente /ToUnicode provoca un consumo de memoria excesivo durante la extracción de texto. La segunda, GHSA-fwg2-594c-jp42 (CVE-2026-71852, CVSS 4.8), documenta un problema similar en el procesamiento de rangos de ancho de fuentes CID, donde un control insuficiente de iteraciones alarga la ejecución y eleva el uso de memoria. Ambas fueron reportadas por los investigadores stefan6419846 y 7thParkk, y quedan corregidas en pypdf 6.15.0. Ninguna de las dos fallas permite ejecutar código ni acceder a archivos fuera del proceso: el riesgo es de denegación de servicio, y requiere que una aplicación procese un PDF controlado por un atacante sin límites de tiempo o memoria, un patrón común en servicios que aceptan documentos subidos por usuarios para extraer texto o generar miniaturas. pypdf es una de las bibliotecas de manejo de PDF más descargadas del índice de paquetes de Python, presente en flujos de trabajo de firma electrónica, generación de reportes y digitalización de documentos. La información de esta nota proviene únicamente de GitHub Advisory Database, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no lleva un registro propio de aplicaciones locales que dependan de pypdf, pero cualquier equipo de zona franca o del sector público costarricense que procese PDF cargados por usuarios —trámites en línea, portales de facturación electrónica— debería confirmar si corre una versión anterior a la 6.15.0 antes de exponer ese flujo a documentos sin origen verificado.
— Las dos fichas, publicadas el 6 y 7 de agosto, describen cómo un PDF diseñado a propósito puede disparar consumo excesivo de memoria o tiempos de ejecución largos durante la extracción de texto.
GitHub anunció, en una entrada de su registro de cambios publicada el 28 de julio de 2026, que npm empezó a escanear automáticamente en busca de malware cada paquete nuevo en el momento de su publicación, antes de que quede disponible para instalación. El proceso añade una demora típica de cinco minutos, que puede extenderse a quince o más en horas de mayor tráfico o según el tamaño y contenido del paquete, según el propio aviso. Operaciones que dependen de que la versión ya esté publicada —como npm deprecate o npm unpublish— no funcionan hasta que el paquete supera el escaneo; si un paquete queda bloqueado, quien lo publicó recibe una notificación con opción de apelar. La medida llega dentro del mismo ciclo de refuerzos de seguridad que esta sección viene documentando desde el 4 de agosto, cuando el gusano ChainDrop comenzó a propagarse por paquetes de Keyv y, luego, de empresas como Deliveroo y Qlik. GitHub también introdujo un campo contentPolicy en el package.json y un archivo DISCLOSURE obligatorio para paquetes que declaran de forma legítima contenido que un escáner automático podría confundir con malware —herramientas de pruebas de penetración, por ejemplo—, además de exigir autenticación de dos factores para publicar. La compañía no detalló, en el aviso consultado para esta nota, qué porcentaje de los paquetes bloqueados hasta ahora correspondió a falsos positivos frente a amenazas reales. La información de esta nota proviene únicamente del registro de cambios oficial de GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de publicaciones a npm desde el país, pero cualquier equipo local con flujos de integración continua que asuman que un paquete queda instalable de inmediato tras publicarse debería ajustar esos flujos a la nueva demora, sobre todo si automatizan despliegues que dependen de una versión recién publicada.
cat /feed/herramientasdevgithubcopilot.md
El cambio, publicado el 7 de agosto en el registro de cambios de GitHub, revierte una configuración que activaba a Copilot como revisor de cada pull request sin que el equipo lo pidiera.
> > github code-quality --status
> GitHub confirmó, en una entrada de su registro de cambios publicada el 7 de agosto de 2026, que activar GitHub Code Quality en un repositorio ya no crea automáticamente una regla (ruleset) que solicita una revisión de código a GitHub Copilot en cada pull request. En los repositorios donde esa regla ya existía, GitHub desactivó por su cuenta las configuraciones asociadas, según el mismo aviso.
> > github code-quality --why
> Cuando Code Quality llegó a disponibilidad general el 20 de julio de 2026, activarlo creaba una regla que sumaba a Copilot como revisor de forma automática. GitHub revirtió esa decisión después de recibir observaciones de usuarios que consideraban que sumar un revisor —humano o automatizado— debía ser una elección explícita del equipo, no un efecto colateral de activar una función de calidad de código, según el aviso. La compañía desactivó tres configuraciones específicas, entre ellas la solicitud automática de revisión de Copilot y la revisión automática de cada nuevo push.
> > github code-quality --next
> GitHub no precisó, en la entrada consultada para esta nota, cuántos repositorios tenían la regla activa antes de la reversión ni si planea ofrecer la opción de reactivarla de forma manual y explícita. La información de esta nota proviene únicamente del registro de cambios oficial de GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de GitHub Code Quality, pero equipos de desarrollo en zonas francas tecnológicas que ya activaron la función esta semana deberían revisar la configuración de revisores de sus repositorios, en lugar de asumir que Copilot dejó de revisar código en los que lo habían solicitado a propósito.
Entre una falla crítica con pérdidas millonarias y ocho advisorías sobre bibliotecas de Git, esta edición documenta seis desarrollos del 4 al 7 de agosto en el ecosistema de programación.
Esta edición documentó seis desarrollos entre el 4 y el 7 de agosto de 2026: una falla crítica de entropía insuficiente en crypto-js que GitHub incorporó a su Advisory Database con pérdidas superiores a USD 5 millones, según Coinspect; ocho fichas de seguridad sobre las bibliotecas cliente de Git GitPython y go-git, dos de ellas con ejecución remota de código; cuatro fallas moderadas en los frameworks Hono y SvelteKit, publicadas el mismo día pese a haber sido reportadas semanas antes; dos advisorías de denegación de servicio en pypdf; la activación del escaneo de malware al publicar en npm; y la decisión de GitHub de dejar de sumar a Copilot como revisor automático de código al activar Code Quality. El hilo que atraviesa la semana en esta sección sigue siendo la seguridad de la cadena de suministro de herramientas de desarrollo, abierto el lunes con el ataque a Keyv y la escalada del gusano ChainDrop. Lo que agregó hoy la edición es una lectura distinta de ese hilo: buena parte de las ocho fichas de GitPython, go-git, Hono y SvelteKit no son fallas nuevas del 7 de agosto, sino asesorías reportadas entre finales de julio y comienzos de agosto que GitHub apenas terminó de revisar y publicar esta semana, dentro del atraso que su propio blog de seguridad reconoció este año. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas nuevas: actualizar crypto-js a la versión 4.0.0 o superior en cualquier proyecto que aún dependa de la rama 3.x, revisar si automatizaciones internas usan GitPython o go-git con parámetros controlados por terceros, actualizar Hono a la 4.12.34 y SvelteKit a la 2.70.2, y ajustar cualquier flujo de integración continua que asuma que un paquete de npm queda instalable de inmediato tras publicarse.