GitHub formalizó en un solo día 15 identificadores CVE para vulnerabilidades de Scriban corregidas entre marzo y julio, mientras Cloudflare sostiene su sexto lanzamiento consecutivo de workerd, Next.js suma un canario más y Kubernetes y Go avanzan hacia sus próximas versiones mayores.
GitHub asignó, el 16 de agosto de 2026, identificadores CVE formales a 15 fallas de seguridad de Scriban, el motor de plantillas de código abierto para .NET que usan proyectos como Elsa Workflows y numerosas plataformas de generación de documentos, según muestra la base de datos de GitHub Advisory. Las dos fallas más graves —CVE-2026-74790, con una puntuación CVSS de 9,3 sobre 10, y CVE-2026-73061, con la misma puntuación— afectan a la clase TypedObjectAccessor, el componente que Scriban usa para decidir qué propiedades de un objeto .NET puede leer o modificar una plantilla. La primera permite que una instancia de TemplateContext reutilizada exponga miembros que un filtro más estricto debía ocultar, porque el sistema guarda en caché el descriptor de acceso por tipo de objeto sin tomar en cuenta cambios posteriores en ese filtro; la segunda permite que una plantilla escriba directamente en propiedades con métodos de escritura privados, internos o de solo inicialización (init), algo que la reflexión de .NET no bloquea por sí sola, según describen ambos avisos. Ninguna de las dos fallas es nueva: los propios avisos de GitHub, consultados para esta nota, remiten a documentos anteriores —GHSA-5wr9-m6jw-xx44 y GHSA-7jvp-hj45-2f2m— publicados el 22 de marzo y el 30 de mayo de 2026, respectivamente, y ya corregidos en las versiones 7.0.0 y 7.2.2 de Scriban. Lo que ocurrió el 16 de agosto fue la asignación retroactiva de un número CVE formal a esos hallazgos, además de un recálculo de severidad bajo el esquema CVSS 4.0 —la falla de marzo pasó de 9,1 a 9,3, la de mayo pasó de 7,7 a 9,3 también—, no el descubrimiento de un problema activo. El detalle importa porque buena parte de las herramientas de análisis de composición de software (SCA) que usan equipos de seguridad solo marcan una alerta cuando existe un identificador CVE: durante los cinco meses entre el parche y el número CVE, un proyecto podía correr una versión de Scriban ya corregida sin que ningún escáner automatizado se lo confirmara por esa vía. La información de esta nota proviene únicamente de 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 adopción de Scriban, pero la biblioteca circula como motor de plantillas en sistemas de facturación electrónica y generación de reportes construidos sobre .NET en empresas locales, a las que conviene confirmar hoy mismo que corren la versión 7.2.2 o superior —el parche real, no el número CVE, es lo que cierra el riesgo— y revisar si sus herramientas de escaneo de dependencias dependían solo de identificadores CVE para marcar vulnerabilidades de código abierto.
Los otros 13 avisos que GitHub sumó el 16 de agosto de 2026 a su catálogo de Scriban documentan, en su mayoría, variantes de denegación de servicio: CVE-2026-74789, con una puntuación CVSS de 8,7, describe cómo operaciones integradas como array.size o la multiplicación de cadenas (string * int) sorteaban el límite de iteraciones LoopLimit —pensado para frenar bucles costosos dentro de una plantilla— porque ese control solo vigilaba las instrucciones explícitas de bucle, no las funciones integradas; CVE-2026-74795, con la misma puntuación de 8,7, describe cómo una plantilla con miles de paréntesis o bloques anidados podía agotar la pila del proceso .NET y provocar una excepción de desbordamiento de pila que, según el propio aviso, "no puede capturarse en .NET" y termina el proceso de forma irrecuperable. El aviso de esta segunda falla no precisa qué versión de Scriban la corrige. El caso de CVE-2026-74789 vuelve a mostrar el patrón de la edición: el aviso GHSA-c875-h985-hvrc, publicado el 22 de marzo de 2026, ya describía exactamente el mismo problema —el ejemplo que usa, la expresión {{ 1..1000000 | array.size }}, es textualmente idéntico— y ya lo daba por corregido en la versión 7.0.0. La diferencia entre marzo y agosto no es técnica sino administrativa: en marzo el hallazgo tenía aviso de GitHub pero no número CVE; en agosto obtuvo el número, lo que lo hace visible para herramientas que filtran por CVE en lugar de por aviso de GitHub. Ese desfase de cinco meses es el ángulo que esta sección considera más relevante de la jornada: no hay una ola nueva de fallas críticas en Scriban, hay un catálogo de seguridad que está poniendo al día su propia numeración. La información de esta nota proviene únicamente de 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 adopción de Scriban, pero a cualquier equipo local que dependa de escáneres de vulnerabilidades basados exclusivamente en CVE —y no en avisos de GitHub sin CVE asociado— le conviene revisar hoy si esa dependencia le dejó puntos ciegos durante los últimos cinco meses, más allá de si ya corre la versión parchada.
cat /feed/devopscloudflareworkers.md
La versión 1.20260817.1, publicada esta madrugada, extiende a seis días consecutivos la cadencia de publicaciones automatizadas del motor de Cloudflare Workers, hoy sin variaciones documentadas en el registro de cambios.
> > workerd --version
> Cloudflare publicó, el 17 de agosto de 2026 a las 00:49 UTC, la versión 1.20260817.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la sexta versión que la compañía publica en otros tantos días consecutivos —esta sección documentó, el 13 y el 16 de agosto, las anteriores de esa racha—, pero a diferencia de esas, la comparación de código entre esta versión y la anterior muestra un solo cambio, identificado como "Release 2026-08-17" y limitado a dos archivos, sin ninguna modificación funcional detallada en las notas de lanzamiento consultadas para esta nota.
> > workerd diff v1.20260816.1..v1.20260817.1
> La versión previa, 1.20260816.1, publicada el 16 de agosto, sí trajo un cambio concreto: la eliminación de código de serialización obsoleto que usaba el método Cache PUT, según el mismo registro. Esta sección viene siguiendo el ritmo de publicación de workerd desde el 12 de agosto como hilo semanal, precisamente porque la cadencia —una versión nueva casi cada 24 horas, generada por el propio flujo de integración continua de Cloudflare— es en sí misma una práctica poco habitual frente al resto del ecosistema de infraestructura de código abierto, donde los lanzamientos semanales o mensuales son la norma; la versión de hoy, sin cambios documentados, confirma que la cadencia se sostiene incluso en los días sin novedades que reportar.
> > echo $COSTA_RICA
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare 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 equipos locales de zonas francas tecnológicas que ya corren funciones de borde sobre la plataforma pueden tratar esta versión como una actualización de mantenimiento sin acción pendiente, a diferencia de la del 16 de agosto, que sí retira una ruta de código que algún proyecto propio pudiera usar.
Vercel publicó, el 16 de agosto de 2026, la versión 16.3.1-canary.21 de Next.js, según el registro oficial de lanzamientos del proyecto en GitHub, firmado por los colaboradores unstubbable, gnoff y acdlite. Los cuatro cambios que trae son menores: ancla las instancias de almacenamiento asíncrono local (async local storage) a símbolos globales, para evitar que distintas copias del módulo en un mismo proceso pierdan sincronía; reorganiza los módulos del enrutador de cliente; corrige una prueba inestable (deflake) sobre el comportamiento de caché con tamaño cero; y agrega el andamiaje inicial —sin activarla todavía— de una bandera experimental llamada concurrentRouterQueue, según describe el propio registro de cambios. La versión llega tres días después de que Next.js publicara su primera etiqueta estable, la 16.3.1, el 13 de agosto, que esta sección cubrió como el cierre de semanas de canarios centrados en el empaquetador Turbopack. Que Vercel siga publicando canarios sobre esa misma base, sin haber anunciado todavía una fecha para la siguiente versión estable, confirma el patrón que esta sección viene señalando: el ciclo de afinamiento no se detuvo con la etiqueta estable, sino que se mudó a una rama paralela que sigue recibiendo cambios casi a diario, ahora con la bandera concurrentRouterQueue como la próxima pieza experimental a seguir. 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 sigue siendo una opción dominante entre agencias y startups locales que construyen aplicaciones web con React, a las que conviene seguir fijando la versión 16.3.1 en producción y dejar los canarios posteriores, incluida la bandera concurrentRouterQueue, para entornos de prueba.
— La versión, publicada el 16 de agosto, reorganiza los módulos del enrutador de cliente y prepara una bandera experimental para colas concurrentes de enrutamiento, sin fecha anunciada para una versión estable posterior a la 16.3.1.
El proyecto Kubernetes publicó, el 6 de agosto de 2026, la primera candidata a lanzamiento de la versión 1.37 (v1.37.0-rc.0), según el registro oficial de lanzamientos en GitHub, con la versión estable prevista para el 26 de agosto según el calendario de lanzamientos que mantiene el propio proyecto. Entre los cambios que trae esa candidata, según el blog oficial del proyecto: la graduación a estable (GA) de la API de métricas (Metrics API); soporte alfa para etiquetas y tolerancias de dispositivo (device taints and tolerations) dentro de la asignación dinámica de recursos (DRA), pensado para que un nodo pueda marcar un dispositivo de hardware como no disponible sin sacar todo el nodo de servicio; y límites de recursos del sistema operativo por contenedor (per-container ulimits). La misma candidata avanza varias depreciaciones que Kubernetes viene anunciando desde hace releases: la bandera kubectl run --filename queda marcada para retiro, los pods estáticos ya no podrán referenciar Secrets ni ConfigMaps, el modo ipvs de kube-proxy sigue su proceso de depreciación de varias versiones, y el soporte para cgroup v1 continúa su camino hacia la eliminación. Esta sección no pudo confirmar de forma independiente cada detalle de esa lista más allá de lo que documentan el registro de lanzamientos de GitHub y el calendario oficial del proyecto, por lo que la fecha del 26 de agosto para la versión estable se mantiene sujeta a que el ciclo de candidatas no se extienda, como ha ocurrido en releases anteriores. Costa Rica no publica cifras propias de adopción de Kubernetes, pero el orquestador es el estándar de facto entre empresas de zonas francas tecnológicas y bancos locales que operan cargas de contenedores en la nube pública, a los que conviene revisar la lista de depreciaciones de la 1.37 —en particular el fin de Secrets y ConfigMaps en pods estáticos— antes de que la versión estable llegue el 26 de agosto.
El equipo de Go publicó, el 13 de agosto de 2026, la tercera candidata a lanzamiento de la versión 1.27 (go1.27rc3), revisada por Dmitri Shuralyov y Mark Freeman, según el registro oficial de cambios en el repositorio del proyecto en GitHub. La rama de lanzamiento (release-branch.go1.27) seguía activa al 15 de agosto, dos días después de esa candidata, sin que el proyecto haya publicado todavía la etiqueta go1.27.0 que marcaría la disponibilidad general —a diferencia de go1.26.6 y go1.25.13, dos versiones de mantenimiento que Go sí publicó en definitivo el 13 de agosto, junto con la candidata. Medios especializados en el lenguaje, entre ellos Northeast Times y varios blogs técnicos del ecosistema Go, han descrito la versión 1.27 como una de las más cargadas del año: reportan que sumaría métodos genéricos —la posibilidad de declarar funciones genéricas dentro del espacio de nombres de un tipo de dato concreto—, un paquete de criptografía poscuántica, una reescritura del motor de codificación JSON y un paquete de identificadores UUID en la biblioteca estándar. Esta redacción no pudo confirmar ese listado de forma directa en las notas de lanzamiento oficiales al cierre de esta edición, por lo que lo consigna con la fuente que lo reporta, no como hecho verificado de forma independiente. Costa Rica no publica cifras propias de adopción de Go, pero el lenguaje tiene uso activo en equipos de backend de fintech y empresas de zonas francas tecnológicas que corren microservicios en el país, a los que conviene tratar go1.27rc3 como material de prueba en integración continua y esperar la etiqueta go1.27.0 antes de fijarlo en producción.
Entre 15 avisos de seguridad que resultaron ser fallas ya corregidas y dos lenguajes que se acercan a sus próximas versiones mayores, esta edición documenta seis desarrollos recientes en el ecosistema de programación.
Esta edición documentó seis desarrollos entre el 6 y el 17 de agosto de 2026: los 15 avisos CVE que GitHub asignó de golpe a fallas de Scriban corregidas entre marzo y julio, dos de ellas con CVSS 9,3; la sexta versión consecutiva de Cloudflare workerd, hoy sin cambios documentados; el canario 16.3.1-canary.21 de Next.js, que reorganiza el enrutador de cliente; la primera candidata de Kubernetes 1.37, con la API de métricas graduando a estable de cara al 26 de agosto; y la tercera candidata de Go 1.27, todavía sin fecha de versión final. El hilo que abre la semana es el desfase entre parche y catalogación: Scriban corrigió sus fallas más graves en marzo y mayo, pero GitHub solo les asignó número CVE este 16 de agosto, lo que durante cinco meses dejó ciego a cualquier escáner de dependencias que filtrara solo por ese identificador. Esta sección adopta, a partir de hoy, a Cloudflare Workers y su motor workerd como personaje de la semana: la cadencia de lanzamiento casi diaria que sostiene desde hace más de una semana —incluida la versión de hoy, publicada sin cambios que reportar— es, en sí misma, un caso de estudio sobre cómo un equipo de plataforma sostiene integración continua a ese ritmo incluso en los días sin novedades. Para equipos de desarrollo en Costa Rica, la lista de hoy suma tareas concretas: confirmar que cualquier proyecto con Scriban corra la versión 7.2.2 o superior, más allá de si el escáner de dependencias ya marcó alerta por CVE; revisar la lista de depreciaciones de Kubernetes 1.37, en particular el fin de Secrets y ConfigMaps en pods estáticos, antes del 26 de agosto; y tratar tanto go1.27rc3 como los canarios de Next.js como material de prueba, no de producción.