Diez vulnerabilidades corregidas en .NET, un aumento de sondeos contra VMware vCenter y una nueva entrega de Cloudflare Workers abren una edición que también sigue la iteración de Terraform y del empaquetador Turbopack de Next.js.
Microsoft publicó, el 11 de agosto de 2026, las actualizaciones de servicio 10.0.11, 9.0.19 y 8.0.30 de .NET, según el registro oficial de lanzamientos del proyecto dotnet/core en GitHub. Las tres versiones corrigen el mismo conjunto de diez vulnerabilidades —CVE-2026-62871, CVE-2026-62886, CVE-2026-62897, CVE-2026-62898, CVE-2026-62899, CVE-2026-62900, CVE-2026-62901, CVE-2026-62902, CVE-2026-62909 y CVE-2026-70354—, que según las mismas notas de lanzamiento incluyen dos fallas de ejecución remota de código (CVE-2026-62897 y CVE-2026-70354), tres de elevación de privilegios, tres de divulgación de información, una de omisión de una función de seguridad y una de denegación de servicio. Microsoft publicó la misma tanda de parches para .NET 11.0.0, todavía en fase preliminar, en su séptima versión de vista previa (preview.7), también del 11 de agosto. Que las tres ramas con soporte activo —8, 9 y 10— reciban el mismo paquete de correcciones el mismo día confirma que las fallas afectan a componentes compartidos del runtime y de bibliotecas base como ASP.NET Core y Entity Framework Core, no a una versión aislada; cualquier aplicación en producción sobre .NET 8, 9 o 10 queda expuesta hasta aplicar la actualización, incluidas las que corren en contenedores o en servidores con parches automáticos deshabilitados. Las notas de lanzamiento consultadas para esta nota no detallan la gravedad individual de cada CVE ni un vector de explotación específico más allá de la clasificación general por tipo de falla. Microsoft no precisó, en el registro de lanzamientos consultado, si alguna de las diez fallas tiene evidencia de explotación activa al cierre de esta edición. La información de esta nota proviene únicamente de las notas de lanzamiento oficiales de dotnet/core en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de .NET, pero el runtime es una opción común en sistemas de banca y aseguradoras locales que corren aplicaciones sobre Windows Server, a los que conviene aplicar hoy mismo las actualizaciones 10.0.11, 9.0.19 u 8.0.30 según la versión que tengan en producción.
Broadcom corrigió, el 29 de julio de 2026 mediante el aviso VMSA-2026-0006, dos fallas críticas en VMware vCenter Server: CVE-2026-59309, una omisión de autenticación en el Servicio de Directorio de VMware (vmdir) con puntuación CVSS de 9,8 que permite a un atacante con solo acceso de red tomar control del plano de administración sin credenciales válidas, y CVE-2026-59310, una ejecución remota de código relacionada, según el análisis técnico de Rapid7. El 11 de agosto, el investigador que opera la cuenta DefusedCyber reportó, según recogió CyberSecurityNews, un aumento de sondeos contra instancias de vCenter expuestas a internet, con solicitudes POST al endpoint /sdk/ que invocan RetrieveServiceContent y recorridos del flujo de inicio de sesión único /websso —ambos coincidentes con la superficie de ataque de CVE-2026-59309. Un servidor vCenter comprometido no queda aislado: administra el plano de control de la infraestructura virtualizada completa de una organización, con acceso a máquinas virtuales, credenciales y configuración de red, según describe Rapid7 en su análisis de la falla. Pero el aumento de sondeos no equivale a explotación confirmada: al cierre de esta edición no hay evidencia pública de que algún atacante haya usado CVE-2026-59309 para comprometer un servidor real, ni existe código de prueba de concepto público, según las fuentes consultadas para esta nota —el propio reporte de DefusedCyber se describe a sí mismo como una alerta temprana, no como confirmación de explotación activa. Broadcom no ha respondido, en las fuentes consultadas, cuántas instancias de vCenter permanecían sin parchear al 11 de agosto. Las versiones corregidas son 9.1.0.0300, 9.0.2.0100 y 8.0 Update 3k, sin solución alternativa disponible para quien no pueda actualizar de inmediato. Costa Rica no publica cifras propias de instancias de vCenter expuestas, pero VMware es una plataforma común de virtualización en centros de datos de bancos y empresas de zonas francas tecnológicas del país, a los que conviene confirmar hoy mismo si sus servidores ya corren una de las tres versiones corregidas y, de no ser así, restringir el acceso de red a vCenter mientras aplican el parche.
cat /feed/herramientasdevcloudflareworkers.md
La versión, publicada el 11 de agosto junto con dos nuevas versiones de workerd, suma comandos para administrar secretos de vista previa y respeta la variable DO_NOT_TRACK para desactivar la telemetría.
> > wrangler --version
> Cloudflare publicó, el 11 de agosto de 2026 a las 19:22 UTC, la versión 4.121.0 de wrangler, la herramienta de línea de comandos de Cloudflare Workers, según el registro oficial de lanzamientos del monorepo workers-sdk en GitHub. La nueva versión suma comandos para administrar secretos de configuración de vista previa (wrangler preview base-config secret put, delete, list y bulk), permite crear bases de datos D1 en jurisdicción de Estados Unidos con la bandera --jurisdiction us, agrega email.sending como origen de suscripción de colas y hace que wrangler respete la variable de entorno DO_NOT_TRACK=1 para desactivar la telemetría. El mismo día, y al día siguiente, Cloudflare publicó dos versiones de workerd, el motor de código abierto que sostiene Workers: la 1.20260811.1, con un nuevo callback ActorObserver para Durable Objects y la implementación de import.meta.dirname e import.meta.filename, y la 1.20260812.1, publicada a las 00:50 UTC del 12 de agosto, que endurece la función checkSignal() y copia datos fuera del entorno aislado (sandbox) en varios componentes internos, según las notas de lanzamiento de ambas versiones.
> > wrangler --why
> Esta sección ya documentó, el lunes y el martes de esta semana, la reescritura de ruptura de Miniflare hacia una API basada en configuración y el ritmo casi diario de publicaciones de workerd; la versión 4.121.0 de wrangler es la pieza que faltaba para que ese conjunto de herramientas locales use la misma forma de configuración en todo el flujo de desarrollo. La opción --jurisdiction us para D1 responde a un requisito recurrente de equipos que necesitan mantener sus datos dentro de Estados Unidos por motivos regulatorios, mientras que respetar DO_NOT_TRACK alinea a Cloudflare con una convención de privacidad que ya usan otras herramientas de línea de comandos del ecosistema JavaScript.
> > wrangler --next
> Cloudflare no precisó, en las notas consultadas para esta nota, si el endurecimiento de checkSignal() en workerd 1.20260812.1 corrige una falla de seguridad específica más allá de la mención genérica a pruebas de regresión reforzadas. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workers SDK y workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Cloudflare Workers, pero la plataforma sigue siendo una opción común para funciones de borde entre equipos de zonas francas tecnológicas que ya usan Cloudflare como red de entrega de contenido, a los que conviene revisar si sus bases D1 necesitan jurisdicción de datos en Estados Unidos antes de aprovechar la nueva bandera.
HashiCorp publicó, el 5 de agosto de 2026, la segunda versión beta de Terraform 1.16, según el registro oficial de lanzamientos del proyecto en GitHub. La beta suma almacenamiento privado de datos para proveedores entre los ciclos de planificación y aplicación, un nuevo bloque store dentro de terraform_data pensado para valores efímeros y sensibles, soporte para usar bloques import dentro de módulos —antes limitados al módulo raíz—, binarios precompilados para Linux s390x (zLinux) y modos on_failure (halt, taint o continue) para los disparadores de acciones de recursos. Siete días después, el 12 de agosto a las 12:01 UTC, el proyecto publicó una compilación alfa nocturna, 1.17.0-alpha20260812, que corrige un error por el cual las funciones pow y log entraban en pánico cuando el resultado no era un número, y añade un campo format_version a la salida JSON del comando de versión. El bloque store y el almacenamiento de datos privados entre ciclos responden a una limitación real de la versión actual de Terraform: hoy, un proveedor no tiene forma de guardar un valor sensible o temporal que sobreviva entre la fase de planificación y la de aplicación sin exponerlo en el archivo de estado, según describe HashiCorp en la propia entrada de cambios de la beta. Permitir bloques import dentro de módulos, en cambio, resuelve una queja frecuente de equipos de plataforma que organizan su infraestructura en módulos reutilizables y que hasta ahora debían mover la lógica de importación al módulo raíz de cada proyecto. HashiCorp no fijó, en las notas consultadas para esta nota, una fecha de disponibilidad general para Terraform 1.16 más allá de la fase beta. La información de esta nota proviene únicamente del registro de lanzamientos oficial 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 la opción dominante de infraestructura como código entre equipos de plataforma de zonas francas tecnológicas que administran recursos en AWS, Google Cloud o Azure, a los que conviene revisar si su flujo de importación de recursos se beneficia de import dentro de módulos antes de que la versión 1.16 llegue a estable.
El equipo de Next.js, el framework de React mantenido por Vercel, publicó cinco versiones candidatas de la rama 16.3.1 entre el 8 y el 11 de agosto de 2026 —canary.9 a canary.13—, según el registro oficial de lanzamientos del proyecto en GitHub. La más reciente, canary.13, del 11 de agosto a las 23:51 UTC, separa la construcción del árbol de carga (loader tree) del orden de los componentes hijos y suma retención de versiones obsoletas con tiempo de vida configurable en el caché de Turbopack, el empaquetador escrito en Rust que Next.js promueve como reemplazo de Webpack. Versiones anteriores de la misma tanda corrigieron bucles de precarga (prefetch) causados por el enrutamiento optimista, sumaron reducción de eliminación de código muerto (tree-shaking) de módulos CommonJS y previnieron interbloqueos (deadlocks) de ámbito y bloque dentro del propio Turbopack. La concentración de cinco versiones en cuatro días, todas con cambios internos de Turbopack y ninguna con funciones nuevas de cara al desarrollador, refleja que el empaquetador sigue en una fase de estabilización de rendimiento antes de convertirse en el valor por defecto de Next.js; Vercel no ha fijado, en el registro de cambios consultado, una fecha para ese cambio de valor por defecto. Cada corrección de este tipo —interbloqueos, bucles de precarga, tree-shaking— ataca directamente las quejas más comunes de equipos que probaron Turbopack en proyectos grandes y reportaron compilaciones que colgaban o repetían peticiones de red sin razón aparente. Next.js no publicó, en las notas consultadas para esta nota, un cronograma para promover la rama 16.3.1 de candidata a versión estable. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Next.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 Next.js, pero el framework es una elección frecuente entre agencias de desarrollo web y startups locales que construyen aplicaciones sobre React, a las que conviene seguir usando la rama estable en producción y reservar las candidatas 16.3.1 para entornos de prueba mientras Turbopack termine de estabilizarse.
— Entre el 8 y el 11 de agosto, el equipo de Next.js publicó cinco versiones candidatas de la rama 16.3.1 centradas en el empaquetador Turbopack, con mejoras de caché y corrección de bucles de navegación.
Entre diez fallas corregidas en .NET y el escaneo activo de una falla crítica en VMware vCenter, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos entre el 5 y el 12 de agosto de 2026: la actualización de servicio de agosto de Microsoft, que corrigió diez vulnerabilidades compartidas entre .NET 8, 9 y 10, dos de ellas de ejecución remota de código; el aumento de sondeos que el investigador DefusedCyber reportó contra servidores VMware vCenter vulnerables a CVE-2026-59309, la omisión de autenticación con CVSS 9,8 que Broadcom corrigió el 29 de julio; la versión 4.121.0 de wrangler junto con dos nuevas versiones de workerd, que suman jurisdicción de datos en Estados Unidos para bases D1 y endurecen funciones internas de seguridad; la beta 2 de Terraform 1.16, con almacenamiento privado de datos entre proveedores y bloques import dentro de módulos; y cinco versiones candidatas de Next.js centradas en el rendimiento y la estabilidad del empaquetador Turbopack. El hilo que esta sección viene documentando desde finales de julio —la seguridad de la cadena de suministro y de la infraestructura de desarrollo— sigue vivo hoy en dos frentes distintos: un parche de Microsoft que llega antes de que se reporte explotación, y una falla de VMware que Broadcom ya corrigió hace dos semanas pero que hoy empieza a mostrar señales de interés atacante. Cloudflare Workers, el hilo que esta sección sigue desde el lunes con la reescritura de Miniflare, sumó hoy su tercera entrega de la semana con wrangler y workerd, mientras Terraform y Next.js documentan el ritmo ordinario de la ingeniería de plataforma y de frontend. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas concretas: aplicar hoy mismo las actualizaciones 10.0.11, 9.0.19 u 8.0.30 de .NET; confirmar si los servidores propios de VMware vCenter ya corren 9.1.0.0300, 9.0.2.0100 u 8.0 Update 3k y restringir su acceso de red mientras tanto; y revisar si sus bases D1 de Cloudflare necesitan la nueva jurisdicción de datos en Estados Unidos antes de adoptarla en producción.