JFrog documentó el 28 de agosto una nueva ola del gusano Shai-Hulud, bautizada Trinitite, que comprometió un paquete de npm con más de 150.000 descargas semanales; Cloudflare workerd cumplió veinte días de lanzamientos diarios pero acumula ya dos jornadas seguidas sin una sola línea de código nuevo; GitHub Copilot CLI estabilizó su versión 1.0.82 y ya abrió la siguiente candidata; Node.js corrigió en horas un error que etiquetaba como alfa su propia versión 26.8.0 y estrenó la LTS 24.20.0 "Krypton"; y Terraform llegó a la versión 1.16 con datos privados de proveedores mientras probaba ya una alfa con refresco mínimo.
El 28 de agosto, JFrog detectó una nueva ola de la familia de gusanos Shai-Hulud —bautizada Trinitite— que publicó diez versiones maliciosas del paquete @7nohe/openapi-react-query-codegen en apenas veinte minutos.
JFrog Security Research identificó, el 28 de agosto de 2026, una nueva ola de la familia de gusanos autopropagables Shai-Hulud a la que bautizó Trinitite, que comprometió el paquete de npm @7nohe/openapi-react-query-codegen —una herramienta de generación de código para TanStack Query con más de 150.000 descargas semanales—, según el informe de la firma. El ataque publicó diez versiones maliciosas en dos tandas separadas por apenas veinte minutos, cubriendo todas las líneas de lanzamiento mantenidas del paquete, de acuerdo con JFrog y con la cobertura de GBHackers. El vector de entrada fue un flujo de trabajo de GitHub Actions con permisos excesivos en el repositorio del paquete: los atacantes lo usaron para crear, mediante la API de GitHub, un repositorio nuevo con la descripción "Trinitite: Sponsored by Preview 2 Effects", según el análisis técnico de JFrog. Una vez activo, el gusano roba credenciales de npm, GitHub, proveedores de nube, integración continua, Kubernetes y HashiCorp Vault, y las usa para replicarse hacia cualquier otro paquete al que la cuenta comprometida tenga permiso de publicación, según Socket. Trinitite llega tres semanas y media después de que otra ola de la misma familia, CHAINDROP, comprometiera más de 1.280 paquetes a partir del 4 de agosto —hilo que esta sección documentó ayer— y confirma que el problema no es una campaña puntual sino un patrón que se repite con vectores distintos cada vez. Homebrew, el gestor de paquetes de macOS, sumó apenas este mes un período de enfriamiento por defecto antes de instalar versiones nuevas de dependencias de npm y pip, pensado justamente para dar tiempo a que este tipo de compromiso salga a la luz antes de que un usuario lo instale, según el registro del cambio en GitHub. Esa mitigación no habría detenido a Trinitite: el vector de entrada no fue una instalación apresurada de una versión nueva, sino un flujo de publicación automatizado con permisos que el propio repositorio del paquete tenía configurados, un punto ciego que ningún período de espera corrige. Costa Rica no publica cifras propias de exposición a estas campañas, pero equipos de desarrollo locales que dependen del ecosistema de npm —la base de la inmensa mayoría de proyectos de JavaScript y TypeScript del país— deberían revisar si sus flujos de trabajo de GitHub Actions tienen permisos de escritura más amplios de los estrictamente necesarios, el mismo punto ciego que permitió esta ola. La información sobre Trinitite proviene de JFrog Security Research, con cobertura cruzada de GBHackers y Socket; no hay, al cierre de esta edición, confirmación de paquetes adicionales comprometidos más allá del señalado.
Cloudflare publicó, el 31 de agosto de 2026 a la 1:12 UTC, la versión 1.20260831.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la versión número veinte de una racha diaria que arrancó el 12 de agosto, pero el único commit registrado entre la versión de ayer y la de hoy —firmado, otra vez, por la cuenta automatizada workers-devprod— se llama simplemente "Release 2026-08-31". La comparación de cambios en GitHub muestra que solo dos archivos se modificaron: maximum-compatibility-date.txt, que subió de "2026-09-06" a "2026-09-07", y release-version.txt, que pasó de "2026-08-30" a "2026-08-31" —ambos, ajustes de fecha sin ninguna línea de código de producto involucrada. Es la segunda jornada consecutiva en que la racha se sostiene sobre un corte puramente administrativo, después de que esta sección documentara ayer la primera vez que eso ocurría en diecinueve días. Dos días seguidos sin cambios reales confirman lo que ayer era apenas una sospecha: el contador de "días consecutivos de lanzamiento" mide el calendario del equipo de automatización de Cloudflare, no el ritmo de trabajo de ingeniería que hay detrás. Como esta sección adelantó el domingo, hoy lunes correspondía reevaluar si Cloudflare Workers sigue mereciendo el lugar de personaje de la semana en esta categoría; con la racha ya sin sustancia noticiosa propia dos días seguidos, ese lugar pasa esta semana a la cadena de compromisos de paquetes de npm de la familia de gusanos Shai-Hulud, que hoy suma ya una tercera ola documentada desde agosto. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que corren cargas sobre la plataforma no necesitan ninguna acción con esta versión: es, otra vez, una entrega de mantenimiento sin cambios de comportamiento.
GitHub publicó, el 29 de agosto de 2026, la versión 1.0.82 de Copilot CLI como primera etiqueta estable del ciclo que había abierto dos días antes con las candidatas 1.0.82-0 y 1.0.82-1, según el registro oficial de lanzamientos del proyecto en GitHub. La entrega corrige un error por el cual un mensaje escrito mientras los comandos /worktree o /move preparaban un directorio de trabajo interrumpía el cambio hacia ese directorio, agrega mensajes de autenticación más específicos —como "401 Bad credentials" en lugar de una instrucción genérica de volver a iniciar sesión— y permite expandir las tarjetas de aprobación de planes con la combinación Ctrl+E, de acuerdo con el mismo registro de cambios. Ese mismo 29 de agosto, GitHub abrió ya la candidata 1.0.82-2 del ciclo siguiente, con las mismas correcciones de mensajería de worktree y expansión de tarjetas de plan. El patrón se repite: como esta sección documentó el sábado, Copilot CLI corta una etiqueta estable y, el mismo día o el siguiente, ya tiene abierta la primera candidata del ciclo que sigue, sin pausa entre una serie y otra. La diferencia esta vez es que la candidata 1.0.82-2 no trae funciones nuevas sobre la versión estable que la precede, sino los mismos cambios ya publicados —una señal de que el equipo todavía está afinando el propio proceso de corte de versiones más que sumando funciones. La información de esta nota proviene únicamente del registro oficial de lanzamientos de GitHub Copilot CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de GitHub Copilot CLI, pero la herramienta gana terreno entre equipos de desarrollo locales que automatizan tareas de programación desde la terminal, para quienes la corrección de mensajes de autenticación de hoy sigue siendo la utilidad más concreta de esta serie de lanzamientos.
— La versión 1.0.82, publicada el 29 de agosto, corrige un cruce de mensajes al preparar un worktree y mejora la visibilidad de errores de autenticación; horas después, GitHub abrió ya la candidata 1.0.82-2 del siguiente ciclo.
El equipo de Node.js publicó, el 26 de agosto de 2026, la versión 26.8.0 de la rama Current, que suma capacidades de análisis de bancos de pruebas (benchmark), certificados raíz actualizados a NSS 3.126, los nuevos modos criptográficos SIV y GCM-SIV, mejoras de rendimiento en net.BlockList y clases nuevas para manejo de archivos ZIP (ZipEntry, ZipFile, ZipBuffer), según el registro oficial de lanzamientos del proyecto en GitHub. Horas más tarde, ese mismo día, el equipo publicó la versión 26.8.1 como parche fuera de calendario: la 26.8.0 había quedado etiquetada por accidente como versión alfa al ejecutar node --version, un error de la fuente que el parche revirtió sin tocar ninguna otra función, de acuerdo con la misma fuente. El 26 de agosto también salió la versión 24.20.0, bautizada "Krypton", con mejoras a los ganchos asíncronos (async hooks), al manejo de buffers, al sistema de permisos y con la activación de JSPI de WebAssembly. Que una versión estable saliera con su propio número de versión mal etiquetado —así fuera por unas horas— es el tipo de error que un flujo de publicación automatizado normalmente atrapa antes de llegar al usuario final; que Node.js lo corrigiera con un parche fuera de calendario ese mismo día, en lugar de esperar al ciclo semanal, sugiere que el error se detectó rápido gracias a reportes de la comunidad más que a una prueba interna. La línea 24, que recién adoptó el nombre en clave Krypton, es la versión de soporte extendido (LTS) activa que la mayoría de equipos de producción usa hoy; sus mejoras de esta entrega —permisos, buffers, WebAssembly— son las que de verdad llegan a aplicaciones en producción, a diferencia de las funciones más experimentales de la rama Current. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Node.js en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Node.js, pero el entorno de ejecución es la base de buena parte del desarrollo backend en JavaScript del país, tanto en startups como en zonas francas tecnológicas; equipos que ya corren la línea 24 LTS pueden actualizar a la 24.20.0 "Krypton" sin urgencia, mientras que quienes siguen la rama Current deberían confirmar que están en la 26.8.1 y no en la 26.8.0 mal etiquetada.
La versión 1.16.0, publicada el 26 de agosto, permite a Terraform guardar datos privados de los proveedores entre plan y apply, y llega un día antes de que el proyecto abriera ya una alfa de la serie 1.17 con una opción de refresco mínimo.
HashiCorp publicó, el 26 de agosto de 2026, la versión 1.16.0 de Terraform, la herramienta de infraestructura como código, según el registro oficial de lanzamientos del proyecto en GitHub. La entrega permite que los proveedores conserven datos privados planificados a través de las operaciones de plan y apply, suma un bloque store dentro de terraform_data para manejar valores sensibles, admite bloques anidados como valores computados dentro de los proveedores, agrega binarios para Linux s390x (zLinux) y amplía el comando terraform graph con salida en formato Mermaid, de acuerdo con la misma fuente. Un día después, el 27 de agosto, el proyecto publicó ya la primera alfa de la siguiente serie, 1.17.0-alpha20260827, que suma una opción -minimal-refresh para que terraform plan actualice únicamente los recursos con cambios propuestos en lugar de refrescar el estado completo. El ritmo de HashiCorp desde que IBM completó la compra de la compañía en 2024 se mantiene en ciclos trimestrales para la edición empresarial, pero la rama de código abierto sigue publicando con la cadencia habitual de versiones menores cada pocas semanas; la opción -minimal-refresh de la nueva alfa responde a una queja recurrente de equipos que operan infraestructura grande, donde refrescar el estado completo en cada plan puede tardar minutos incluso sin cambios reales que aplicar. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Terraform en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Terraform, pero la herramienta es una de las más usadas para gestionar infraestructura en la nube entre equipos de DevOps locales, tanto en bancos como en zonas francas tecnológicas, para quienes la opción -minimal-refresh de la alfa 1.17 vale la pena seguir de cerca antes de que llegue a una versión estable.
Entre una nueva ola del gusano Shai-Hulud en npm y la segunda jornada seguida sin cambios de código en Cloudflare workerd, esta edición documenta cinco desarrollos recientes del ecosistema de programación.
Esta edición documentó cinco desarrollos del 26 al 31 de agosto de 2026: la ola Trinitite del gusano Shai-Hulud, que JFrog detectó el 28 de agosto comprometiendo un paquete de npm con más de 150.000 descargas semanales; la versión 1.20260831.1 de Cloudflare workerd, vigésima entrega consecutiva de una racha que arrancó el 12 de agosto pero que ya lleva dos días seguidos sin una sola línea de código; la versión 1.0.82 de GitHub Copilot CLI, que se volvió estable el 29 de agosto con una candidata siguiente abierta el mismo día; la versión 26.8.1 de Node.js, un parche fuera de calendario para corregir un etiquetado erróneo, junto con el estreno de la LTS 24.20.0 "Krypton"; y la versión 1.16.0 de Terraform, ya seguida de una alfa de la serie 1.17. El hilo que domina la jornada es el relevo de personaje de la semana en esta sección: Cloudflare Workers y su motor workerd cierran cuatro ediciones consecutivas en ese lugar, pero una racha sin código de por medio dos días seguidos deja de ser noticia por sí sola. A partir de hoy, el hilo que esta sección sigue con más atención es la cadena de compromisos de paquetes de npm de la familia Shai-Hulud —CHAINDROP el 4 de agosto, Trinitite el 28—, que no muestra señales de agotarse y que las mitigaciones anunciadas hasta ahora, como el período de enfriamiento que Homebrew sumó este mes para npm y pip, no alcanzan a cubrir del todo. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición es revisar los permisos de los flujos de trabajo de GitHub Actions que publican paquetes propios en npm, el mismo punto ciego que permitió la ola Trinitite. El resto de la lista —workerd, Copilot CLI, Node.js y Terraform— queda en fase de observación de rutina, salvo quien siga la rama Current de Node.js, que debería confirmar que corre la 26.8.1 y no la 26.8.0 mal etiquetada.