La beta pública del hipervisor propio de Docker, la compatibilidad con Node.js activada por defecto en Cloudflare Workers y la corrección de una falla de escritura de archivos en SSH.NET abren una edición que también documenta fallas corregidas en SIPSorcery y Fleet, y la última tanda de cambios de ruptura en SvelteKit 3.
Docker Inc. lanzó, el 12 de agosto de 2026, la beta pública de Docker VMM en Windows, según una entrada de blog firmada por Deanna Sparks y Colin Hemmings en el sitio oficial de Docker. Docker VMM es el hipervisor propio que la compañía construyó desde cero para reemplazar la capa de virtualización de terceros que Docker Desktop usaba hasta ahora para crear y administrar la máquina virtual de Linux sobre la que corren los contenedores en Mac y Windows; en Mac ya estaba disponible para quienes se habían sumado a la etapa temprana, y con esta beta cualquier usuario de Windows puede activarla desde Configuración > General sin bandera experimental ni lista de espera, a partir de Docker Desktop 4.86. Según la publicación, el cambio trae arranque de contenedores más rápido, mejor desempeño de lectura y escritura de archivos compartidos entre el contenedor y el equipo local, gestión de memoria que libera RAM cuando los contenedores están inactivos y, en Windows, aislamiento completo respecto a Hyper-V con una velocidad que Docker describe como equivalente a WSL2. Docker no publicó, en la entrada consultada para esta nota, ninguna cifra de referencia (benchmark) que respalde las mejoras que describe como "medibles" —la publicación usa calificativos como "significativamente más rápido" sin comparaciones numéricas contra el motor de terceros que reemplaza, algo que cualquier equipo que evalúe el cambio debería confirmar con sus propias pruebas antes de adoptarlo en flujos de trabajo sensibles al rendimiento. El mismo motor sostiene además Docker Sandboxes (SBX), la herramienta de entornos aislados para agentes que Docker viene promoviendo este año, lo que confirma que la apuesta por un hipervisor propio es una pieza central de su estrategia y no un ajuste aislado de Docker Desktop. La información de esta nota proviene únicamente de la entrada de blog oficial de Docker, sin cobertura cruzada de otro medio verificada al cierre de esta edición. Docker fijó el fin de la beta para el otoño boreal de 2026, con disponibilidad general prevista para fines de octubre, momento en el que Docker VMM pasaría a ser el motor por defecto en instalaciones nuevas de Mac, Windows y Linux, según la misma publicación. Costa Rica no publica cifras propias de adopción de Docker Desktop, pero la herramienta es una opción estándar entre desarrolladores locales que trabajan con contenedores en laptops Mac y Windows, a quienes conviene probar la beta en un proyecto no crítico antes de que se vuelva la opción por defecto en octubre.
La versión 2026.0.0 de la biblioteca .NET, publicada el 9 de agosto y sumada a la base de datos de GitHub el 12, cierra un salto de directorio que un servidor SCP malicioso podía usar para sobrescribir archivos fuera de la carpeta de descarga.
El proyecto SSH.NET publicó, el 9 de agosto de 2026, la versión 2026.0.0 de la biblioteca, que corrige CVE-2026-48798, una falla de salto de directorio (path traversal) con una puntuación CVSS de 7,1 sobre 10, según el aviso de seguridad publicado en la base de datos de GitHub Advisory, indexado el 12 de agosto. El problema está en la función de descarga recursiva del cliente SCP (ScpClient): la biblioteca no validaba los nombres de archivo que devolvía el servidor remoto, de forma que un servidor SCP controlado por un atacante —o interpuesto en un ataque de intermediario— podía enviar rutas con secuencias ../ o rutas absolutas para crear o sobrescribir archivos fuera de la carpeta de destino, en cualquier ubicación donde el proceso cliente tuviera permisos de escritura, según describe el propio aviso. Los responsables del hallazgo, identificados como Nadav0077 e igorpyan, lo describieron como equivalente al de CVE-2019-6111 de OpenSSH, una falla de siete años de antigüedad en el cliente scp original —la recurrencia del mismo patrón de validación faltante en una reimplementación posterior en .NET es, según el propio texto del aviso, la razón del paralelismo explícito. Un atacante que explote la falla podría escribir o modificar archivos sensibles del cliente, como claves SSH o archivos de configuración, lo que el aviso vincula con escenarios de persistencia o escalamiento de privilegios, aunque aclara que la explotación requiere interacción del usuario —iniciar una descarga recursiva contra un servidor no confiable— y no ofrece una solución alternativa más allá de actualizar. La información de esta nota proviene únicamente del aviso de seguridad oficial de SSH.NET en la base de datos de GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de SSH.NET, pero la biblioteca es una opción común entre equipos de desarrollo .NET locales que automatizan transferencias de archivos por SCP desde aplicaciones de escritorio o servicios backend, a los que conviene actualizar a la versión 2026.0.0 antes de conectar el cliente contra cualquier servidor SCP que no controlen por completo.
El proyecto de código abierto SIPSorcery publicó, el 10 de agosto de 2026, la versión 10.0.14 de su biblioteca de comunicaciones en tiempo real para .NET, que corrige dos vulnerabilidades de denegación de servicio documentadas en avisos separados de la base de datos de GitHub Advisory, ambos con CVSS 7,5 sobre 10 y actualizados el 12 de agosto. La primera, sin CVE asignado al cierre de esta edición (GHSA-pfvm-w89x-94jw), está en el componente TurnServer: un solo datagrama UDP malformado, con el primer byte de la cabecera STUN en el rango 0x80 a 0xFF, provoca una excepción que termina el bucle de recepción sin reinicio automático y deja inoperable el relé TURN completo para todos los clientes conectados, sin necesidad de autenticación. La segunda (GHSA-jwjp-4649-v8jp) está en el analizador de fragmentos SACK del protocolo SCTP: un par de WebRTC ya negociado —después del intercambio DTLS— puede enviar un paquete con valores de conteo al máximo (0xFFFF) que hacen que la biblioteca lea más allá del final del búfer de recepción de 262 144 bytes, lo que termina de forma permanente el hilo de recepción SCTP y desactiva todos los canales de datos de esa sesión. Ninguna de las dos fallas tiene todavía un identificador CVE formal asignado por MITRE, según ambos avisos consultados para esta nota, pese a que GitHub las calificó como de severidad alta —una discrepancia habitual entre la calificación de severidad que asigna GitHub mediante su propio proceso de revisión y el ritmo, más lento, de asignación formal de identificadores CVE, que puede dejar a herramientas de escaneo centradas solo en CVE sin visibilidad de fallas ya corregidas. La información de esta nota proviene únicamente de los avisos de seguridad oficiales de SIPSorcery en GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de SIPSorcery, pero la biblioteca se usa en proyectos de videollamadas y telefonía IP construidos sobre .NET, incluido algún soporte técnico remoto; a los equipos locales que la usen en producción les conviene actualizar a la versión 10.0.14 antes de exponer un servidor TURN o un punto de conexión WebRTC a tráfico de internet sin filtrar.
cat /feed/devopscloudflareworkers.md
wrangler 4.122.0, publicado el 12 de agosto, deja de exigir la bandera nodejs_compat en proyectos con fecha de compatibilidad reciente, mientras workerd suma dos versiones más con una corrección de segfault y el endurecimiento de checkSignal().
> > wrangler --version
> Cloudflare publicó, el 12 de agosto de 2026 a las 14:20 UTC, la versión 4.122.0 de wrangler junto con otros nueve paquetes del monorepo workers-sdk —entre ellos create-cloudflare 2.71.1 y @cloudflare/vite-plugin 1.52.0—, según el registro oficial de lanzamientos en GitHub. El cambio central: wrangler ahora detecta la compatibilidad con Node.js a partir de la fecha de compatibilidad (compatibility date) del propio proyecto, en lugar de exigir la bandera nodejs_compat de forma explícita. Desde el 4 de agosto, workerd activa por defecto nodejs_compat y nodejs_compat_v2 para cualquier fecha de compatibilidad posterior a esa, salvo que el proyecto declare no_nodejs_compat o no_nodejs_compat_v2 para desactivarlo; wrangler y create-cloudflare ya no agregan la bandera de forma innecesaria a proyectos nuevos, y el proceso de build ignora banderas redundantes que antes producían errores en tiempo de ejecución. La versión también corrige una falla por la que las sesiones nuevas de enlaces remotos (remote bindings) reutilizaban configuración vieja y devolvían errores de "Binding not found".
> > workerd --version
> El mismo 12 de agosto a las 00:50 UTC, Cloudflare publicó workerd 1.20260812.1, que añade pruebas de regresión para una vulnerabilidad identificada internamente como vulnerability-88 y endurece la función checkSignal(), copia datos fuera del entorno aislado (sandbox) en varios componentes de flujo de datos protegidos por claves de protección de memoria (MPK), y suma metadatos de reintento a los Durable Objects. Un día después, el 13 de agosto a las 00:50 UTC, la versión 1.20260813.1 corrigió un segmento de falla (segfault) en las funciones de desenvoltura (unwrap) de JSG, según el registro de cambios, y ajustó la compilación de las herramientas de macOS para apuntar a macOS 13.5 en lugar de 10.11.
> > workerd --why
> Esta sección documenta el ritmo de publicaciones de Cloudflare Workers desde el lunes de esta semana, cuando cubrió la reescritura de ruptura de Miniflare; la activación por defecto de nodejs_compat es la pieza que cierra ese ciclo, porque alinea a wrangler con el comportamiento que workerd ya tenía desde el 4 de agosto. Cloudflare no detalló, en las notas consultadas para esta nota, la naturaleza exacta de "vulnerability-88" más allá de mencionar que se sumaron pruebas de regresión para ella. 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 los equipos locales de zonas francas tecnológicas que ya corren funciones de borde sobre la plataforma pueden revisar hoy mismo si sus proyectos declaran nodejs_compat de forma explícita, una bandera que a partir de ahora es redundante en compatibilidad reciente.
SvelteKit publicó tres versiones más de la rama de ruptura 3.0.0-next entre el 11 y el 13 de agosto de 2026 —next.20, next.21 y next.22—, según el registro oficial de lanzamientos del proyecto en GitHub. La más relevante, next.21, del 12 de agosto a las 18:10 UTC, suma dos cambios de ruptura: traslada los tipos de funciones remotas y la función isValidationError al nuevo módulo @sveltejs/kit/remote, y mueve RequestEvent y Cookies —hasta ahora exportados desde el paquete raíz— al módulo $app/server. La víspera, next.20, reorganizó los tipos en módulos dedicados adicionales (@sveltejs/kit/params, @sveltejs/kit/hooks, @sveltejs/kit/env) y eliminó el requisito de declarar la ruta #lib; next.22, del 13 de agosto, se limitó a una corrección menor para que el nivel de registro (log level) por defecto de Vite se respete sin sobreescrituras del framework. La secuencia confirma el patrón que esta sección documentó el lunes de esta semana: SvelteKit 3 sigue troceando su superficie de API en módulos más pequeños y explícitos en lugar de sumar funciones nuevas, un enfoque que exige a cualquier proyecto que pruebe la rama next revisar sus importaciones en cada versión, en particular ahora las de funciones remotas y RequestEvent. El equipo no publicó, en las notas consultadas para esta nota, una fecha estimada para una primera versión candidata a lanzamiento. La información de esta nota proviene únicamente del registro de lanzamientos oficial de SvelteKit en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Svelte, pero el framework mantiene una base activa entre agencias de desarrollo web locales, a las que conviene seguir tratando la rama 3.0.0-next como una vista previa de trabajo en progreso.
— Las versiones next.20 a next.22, publicadas entre el 11 y el 13 de agosto, mueven los tipos de funciones remotas y RequestEvent a nuevos módulos y reorganizan la salida del registro de Vite.
El proyecto de código abierto Fleet, la plataforma de administración de dispositivos basada en osquery, publicó el 11 de agosto de 2026 la versión 4.87.0, que corrige CVE-2026-48786, una falla de divulgación de información con una puntuación CVSS de 6,5 sobre 10 clasificada como de severidad moderada, según el aviso de seguridad publicado en la base de datos de GitHub Advisory. El problema estaba en el endpoint de búsqueda de objetivos (target search): a diferencia de otros puntos de la API que sí aplican controles de saneamiento por equipo, este permitía a usuarios autenticados con roles de Observer, Observer+ o Technician —los niveles de acceso más bajos que ofrece Fleet— recuperar los secretos de inscripción (enroll secrets) y las opciones de agente sin enmascarar de cualquier equipo, lo que según el propio aviso podía exponer credenciales como llaves de AWS o contraseñas de proxy configuradas en esas opciones. El riesgo concreto es que un usuario con acceso legítimo pero limitado —pensado solo para consultar el estado de los dispositivos, no para administrarlos— podía usar esas credenciales filtradas para inscribir equipos no autorizados en un equipo (team) de Fleet, ampliando su acceso más allá de lo que su rol debía permitir. La información de esta nota proviene únicamente del aviso de seguridad oficial de Fleet en GitHub Advisory, sin cobertura cruzada de otro medio al cierre de esta edición; el aviso no precisa desde cuándo el endpoint tenía este comportamiento ni si hubo explotación antes del parche. Costa Rica no publica cifras propias de uso de Fleet, pero la herramienta es una opción de código abierto para administración de dispositivos que equipos de seguridad de plataforma de empresas locales evalúan como alternativa a suites comerciales de gestión de endpoints, a los que conviene actualizar a la versión 4.87.0 y revisar si algún usuario con rol de observador tuvo acceso al endpoint de búsqueda de objetivos antes del parche.
Entre la beta pública del hipervisor propio de Docker y una falla de escritura de archivos corregida en SSH.NET, esta edición documenta seis desarrollos recientes en el ecosistema de programación.
Esta edición documentó seis desarrollos entre el 9 y el 13 de agosto de 2026: la beta pública de Docker VMM, el hipervisor propio que Docker construyó para reemplazar la virtualización de terceros en Docker Desktop; la versión 2026.0.0 de SSH.NET, que corrige una falla de escritura de archivos fuera de directorio con CVSS 7,1; las dos denegaciones de servicio de SIPSorcery, ambas con CVSS 7,5 y todavía sin CVE formal asignado; la versión 4.122.0 de wrangler junto con dos nuevas versiones de workerd, que activan por defecto la compatibilidad con Node.js en Cloudflare Workers; tres versiones más de la rama de ruptura SvelteKit 3.0.0-next, que reorganizan funciones remotas y tipos de solicitud; y la versión 4.87.0 de Fleet, que cierra una filtración de secretos de equipo hacia usuarios con acceso de solo lectura. El hilo que esta sección viene siguiendo desde el lunes —la reescritura de las herramientas locales de Cloudflare Workers— cerró hoy su cuarto día consecutivo de publicaciones con la activación por defecto de nodejs_compat en wrangler, mientras el resto de la edición confirma un patrón ya conocido en seguridad de cadena de suministro: fallas de severidad alta en bibliotecas de uso específico —SSH.NET, SIPSorcery, Fleet— que rara vez llegan a la cobertura de medios generalistas pero sí exponen a cualquier equipo que las use sin revisar sus propios avisos de seguridad. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas concretas: actualizar SSH.NET a la versión 2026.0.0 antes de conectar contra servidores SCP no confiables; revisar si algún usuario con rol de observador en Fleet tuvo acceso al endpoint de búsqueda de objetivos antes del parche 4.87.0; y confirmar si los proyectos propios sobre Cloudflare Workers todavía declaran la bandera nodejs_compat de forma explícita, ahora redundante en compatibilidad reciente.