Kubernetes tiene programada para hoy la publicación de la versión 1.37 con dieciséis mejoras a estable, Next.js corrigió el 25 de agosto dos fallas críticas de ejecución remota de código con puntajes CVSS de 9,0 y 9,5, Cloudflare workerd llegó a quince días consecutivos de lanzamientos, personaje de la semana en esta sección, GitHub Copilot CLI sumó su undécima versión desde el 18 de agosto, Prisma publicó la octava candidata de su versión 8, y mise y oxc sumaron correcciones menores entre el 24 y el 26 de agosto.
El equipo de lanzamientos de Kubernetes, sig-release, fijó el 26 de agosto de 2026 como fecha de publicación de la versión 1.37.0, según el calendario oficial del proyecto en kubernetes.dev y la discusión de aspectos destacados publicada en GitHub. La última candidata de prueba, la rc.1, salió el 20 de agosto con el conjunto de funciones ya congelado; dieciséis mejoras gradúan a estable en esta entrega, entre ellas la salida KYAML para kubectl —un dialecto de YAML con llaves para mapas y corchetes para listas, pensado para evitar errores comunes como el llamado "bug de Noruega"—, los recursos a nivel de pod y la API metrics.k8s.io, que llega a estable después de casi nueve años en beta, según el mismo registro. El modo "rootless" del kubelet (Kubelet-in-UserNS), que permite correr los componentes de Kubernetes sin privilegios de raíz en el sistema anfitrión, sube a beta más de cinco años después de su debut en alpha en la versión 1.22. La entrega también trae cambios de ruptura que equipos de plataforma deben revisar antes de actualizar: los pods estáticos —los que el kubelet arranca directamente desde archivos en el nodo, sin pasar por el plano de control— ya no podrán referenciar Secrets ni ConfigMaps, el modo ipvs de kube-proxy continúa su descontinuación por etapas iniciada en versiones anteriores, y el soporte de cgroup v1 sigue camino a su eliminación, según el mismo calendario oficial; el comando kubectl run --filename también queda marcado obsoleto. Ese paquete de rupturas, documentado en el resumen de la versión que publicó el proveedor de registros de paquetes Cloudsmith, es lo que equipos de infraestructura deben auditar antes de programar la actualización, más que las funciones nuevas que acaparan los titulares. Al cierre de esta edición, el repositorio oficial de Kubernetes en GitHub todavía no listaba el tag v1.37.0 como publicado, solo la candidata rc.1 del 20 de agosto —un desfase entre calendario y publicación real que no es inusual en proyectos de código abierto de este tamaño—. Costa Rica no publica cifras propias de adopción de Kubernetes, pero el orquestador es la base de facto de la infraestructura en la nube de bancos, telecomunicaciones y zonas francas tecnológicas del país, para quienes conviene esperar la confirmación formal de la versión estable y revisar primero si sus manifiestos de pods estáticos referencian Secrets o ConfigMaps antes de programar la actualización.
Dos avisos publicados el 25 de agosto describen fallas de ejecución remota sin autenticación —una en servidores Windows, otra en imágenes AVIF— ya corregidas en las versiones 16.3.3 y 15.5.24.
El equipo de seguridad de Next.js, encabezado por Sebastian Silbermann (usuario eps1lon en GitHub), publicó el 25 de agosto de 2026 dos avisos de seguridad críticos junto con las versiones de corrección 16.3.3 y 15.5.24, según el registro oficial de lanzamientos del proyecto en GitHub. El primero, identificado como CVE-2026-75604 (GHSA-p293-qw3h-jr36) con una puntuación CVSS de 9,0 sobre 10, es una falla de recorrido de rutas (CWE-22) que permite ejecución remota de código sin autenticación en aplicaciones Next.js alojadas en servidores Windows que usan el enrutador Pages o App sin el Cache Component; afecta las versiones 13.4 a 15.5.23 y 16.0 a 16.3.2, según el mismo aviso, que acredita el hallazgo a los investigadores evolutionstorm y B0RI. El segundo aviso (GHSA-2xp9-vwfh-vxw4), con una puntuación CVSS de 9,5 sobre 10 y sin número CVE asignado al cierre de esta edición, describe una ejecución remota de código sin autenticación en la API de optimización de imágenes cuando esta procesa archivos AVIF, originada en una falla de la biblioteca libheif que usa la herramienta sharp; afecta las versiones 10.0.0 a 15.5.23 y todas las anteriores a 16.3.3, según el aviso conjunto que publicaron también los mantenedores de libheif (GHSA-g89c-p67h-r497). Ninguno de los dos avisos ofrece una solución alternativa (workaround): la corrección exige actualizar de inmediato a la versión 15.5.24 o 16.3.3, según ambos avisos. Como mitigación temporal mientras el ecosistema completa el parche de libheif, el equipo de Next.js desactivó por completo la optimización de imágenes AVIF en las versiones corregidas. Que una falla sin autenticación y sin mitigación alcance una puntuación de 9,5 sobre 10 —cerca del máximo de la escala CVSS 4.0— la coloca entre las vulnerabilidades más graves reportadas este año en un framework de uso masivo: Next.js impulsa aplicaciones de comercio electrónico, paneles internos y sitios corporativos en todo el mundo, muchos de ellos desplegados sobre servidores Windows en entornos corporativos que no siguen el patrón típico de contenedores Linux. El registro de cambios no precisa cuántas aplicaciones en producción seguían expuestas al cierre de esta edición. Costa Rica no publica cifras propias de aplicaciones Next.js en producción, pero el framework es una de las bases más comunes entre agencias y startups locales que construyen sitios con React —esta sección documentó el 25 de agosto los ajustes de caché de la rama canary de Next.js—, por lo que equipos que alojan sus aplicaciones en servidores Windows o que sirven imágenes AVIF sin pasar por un proxy externo deberían tratar la actualización a 16.3.3 o 15.5.24 como prioridad inmediata, no como mantenimiento de rutina.
cat /feed/devopscloudflareworkers.md
La versión 1.20260826.1, publicada hoy, retoma cambios de código reales por segundo día consecutivo y extiende a quince la racha diaria del motor de Cloudflare Workers, personaje de la semana en esta sección.
> > workerd --version
> Cloudflare publicó, el 26 de agosto de 2026 a las 00:49 UTC, la versión 1.20260826.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la decimoquinta versión consecutiva que la compañía publica en otros tantos días, racha que arrancó el 12 de agosto. La entrega de hoy corrige cómo node:fs cp maneja enlaces simbólicos (symlinks) al copiar hacia subdirectorios, agrega el método ioContext.createObject, implementa la clase DigestStream con TypeScript, suma metadatos de respuesta a los tipos de Browser Run (ticket interno BRAPI-1553) y preserva las etiquetas (tags) de WebSocket en cada copia, según el mismo registro de cambios.
> > workerd diff v1.20260825.1..v1.20260826.1
> Es el segundo día seguido con cambios de código reales, después de que la entrega de ayer sumara la preservación de respuestas automáticas de WebSocket en tránsito y flujos de compresión respaldados por TypeScript. Quince días sin una sola interrupción, del 12 al 26 de agosto, siguen siendo el hilo más sostenido de esta categoría en lo que va del mes, y esta sección mantiene a Cloudflare Workers como personaje de la semana.
> > 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 tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que ejecutan Workers con operaciones de sistema de archivos (node:fs) sobre enlaces simbólicos pueden revisar la corrección de hoy antes de su próxima actualización, según el mismo registro de cambios.
GitHub publicó, el 25 de agosto de 2026 a las 21:15 UTC, la versión 1.0.81-10 de Copilot CLI, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización habilita el panel de plugins para todas las personas usuarias a través de los comandos /plugin, /mcp o /skills —antes limitado— y elimina el comando /plugins, cuyas funciones se redistribuyen entre /plugin, /mcp, /skills, /subagents y /instructions. La tecla x pasa a funcionar como atajo de borrado en la configuración del entorno aislado (sandbox), los ajustes, MCP, el diálogo de sesiones y los comentarios de diff; el modo automático ahora ajusta la selección de modelo sobre la marcha según cambian los requisitos de la tarea durante la conversación, y el panel de estado de Autopilot muestra el último mensaje escrito como el objetivo inferido de la sesión, según el mismo registro. La versión también corrige un bloqueo indefinido en la pantalla de carga que ocurría al activar extensiones de plugins de repositorio. Menos de cuatro horas después, la versión 1.0.81-11, publicada el 26 de agosto a la 01:32 UTC, corrige un problema puntual: un servidor MCP bloqueado por una política empresarial ahora se muestra como bloqueado dentro de /mcp en lugar de quedar girando indefinidamente en estado pendiente, según el mismo registro de cambios. Es ya la undécima entrega de la serie 1.0.81 desde la v1.0.81-1 del 18 de agosto —dos versiones más desde que esta sección documentó la novena el 24 de agosto—, una cadencia que la herramienta sostiene sin interrupciones desde hace más de una semana y que la sitúa, junto con Cloudflare workerd, entre los proyectos con el ritmo de publicación más agresivo que sigue esta sección. 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 asistida, para quienes el panel de plugins abierto a todos y la corrección del bloqueo de MCP no exigen ningún cambio de configuración adicional, según el mismo registro de cambios.
El equipo de Prisma publicó, el 26 de agosto de 2026 a las 08:15 UTC, la versión 8.0.0-rc.8 del ORM, según el registro oficial de lanzamientos del proyecto en GitHub. El cambio de ruptura de esta entrega mueve el motor de referencia (peer) a @prisma/cli-engine@0.3.0 y convierte @prisma/management-api-sdk, hasta ahora una dependencia estándar, en una dependencia de referencia (^1.55.0) que la CLI de Prisma provee en tiempo de ejecución. La versión también corrige la planificación de migraciones para que rechace bases de datos vacías cuando ya existen migraciones en el disco, y en su lugar ofrezca un mensaje de error estructurado con la alternativa de planificar una línea base explícita, según el mismo registro de cambios. La novedad de fondo es la habilidad (skill) "prisma-8", que ahora enseña a los agentes de inteligencia artificial la arquitectura real del sistema de migraciones del ORM —planificación a partir del estado actual con líneas base explícitas, en lugar de una cadena lineal de migraciones—, con el objetivo declarado de evitar que un agente genere un plan de creación completa contra una base de datos de producción, según la misma nota de lanzamiento. Es ya la octava candidata del ciclo de la versión 8 desde que arrancó el 7 de agosto, y como esta sección documentó ayer con el renombre de los métodos take() y skip() a limit() y offset() en la rc.7, el proyecto sigue tocando partes centrales de la API tan tarde como la octava ronda de pruebas —esta vez la forma en que el propio Prisma se distribuye como dependencia, no solo los nombres de sus métodos—, lo que sigue sin despejar cuánto falta para que la versión 8.0.0 estable congele su superficie pública. Prisma no ha publicado, en el registro consultado para esta nota, una fecha estimada para la versión 8.0.0 estable. Costa Rica no publica cifras propias de adopción de Prisma, pero el ORM es una opción común entre startups locales que usan Node.js y TypeScript sobre PostgreSQL en zonas francas tecnológicas, a las que sigue conviniendo posponer cualquier migración de código a Prisma 8 hasta que el proyecto confirme que la superficie de la API —y ahora también sus dependencias de referencia— dejó de cambiar.
— La versión 8.0.0-rc.8, publicada hoy, mueve el motor de referencia a la 0.3.0 y enseña a los agentes de IA a planificar migraciones sin arriesgar bases de datos en producción.
El equipo de mise publicó, el 25 de agosto de 2026 a las 22:28 UTC, la versión 2026.8.13 del gestor de versiones de herramientas de desarrollo, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización suma la opción task_config.excludes, que permite excluir rutas, directorios y patrones glob de la búsqueda automática de tareas —evita que un archivo TOML cualquiera del repositorio se interprete por error como una tarea—; permite dividir la configuración de un proyecto en fragmentos visibles dentro de mise/conf.d/*.toml, que se combinan en orden alfabético; y agrega la bandera --skip-dirty al arranque (bootstrap) para omitir con una advertencia los repositorios con cambios locales sin confirmar. La misma entrega incluye cerca de veinte correcciones, entre ellas la restauración de las sugerencias automáticas dinámicas de la terminal (shell completions) en fish y zsh, y la eliminación de las marcas de orden de bytes UTF-8 en archivos de variables de entorno, según el mismo registro de cambios. Un día después, la versión 2026.8.14, publicada el 26 de agosto a la 01:16 UTC, corrige tres fallas puntuales de instalación: las instalaciones de npm y aube dejaban de crear archivos .npmrc sintéticos dentro de los directorios de herramientas —la configuración ahora va a .config/aube/config.toml—, la intercepción del programa auxiliar (trampoline) de npm no reconocía __node-gyp-bootstrap cuando un script de ciclo de vida invocaba node-gyp, y las extracciones fallidas por HTTP dejaban de limpiar sus directorios temporales, según el mismo registro de cambios. Esta sección documentó el 24 de agosto la migración del analizador de línea de comandos de mise de clap a usage-rs; la entrega de hoy confirma que ese cambio de fondo, publicado apenas hace tres días, sigue sin generar regresiones visibles, mientras el proyecto concentra su ritmo más reciente en depurar instalaciones de paquetes de Node.js en lugar de tocar de nuevo el núcleo del analizador. La información de esta nota proviene únicamente del registro oficial de lanzamientos de mise en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de mise, pero equipos locales que fijan, dentro de un mismo repositorio, las versiones exactas de Node.js, Python o Ruby que necesitan lo usan cada vez más como alternativa a asdf, y quienes instalan paquetes con dependencias nativas vía node-gyp son los que más deberían notar la corrección de hoy.
El proyecto oxc publicó, el 24 de agosto de 2026 a las 13:39 UTC, las versiones 1.80.0 de oxlint y 0.65.0 de oxfmt, según el registro oficial de lanzamientos en GitHub. oxlint suma una sugerencia automática de corrección para la regla typescript/no-confusing-non-null-assertion, corrige cómo la regla eslint/no-useless-rename preserva los modificadores de tipo, ajusta la resolución de globales por referencia en lugar de por nombre, y refina el mensaje de ayuda de la regla eslint/no-control-regex, según el mismo registro de cambios. oxfmt, el formateador de código del mismo proyecto, corrige un caso puntual: preservar los decoradores de una clase antes de la palabra export cuando la sentencia está suprimida. La entrega llega apenas horas después de la versión 0.147.0 de las bibliotecas (crates) de oxc, publicada esa misma mañana, que esta sección ya documentó el 24 de agosto por sus mejoras al minificador y al generador de código. Tres lanzamientos distintos del mismo conjunto de herramientas en un solo día —crates, oxlint y oxfmt— confirman el patrón que domina el proyecto desde hace meses: entregas frecuentes e incrementales de un analizador, linter, formateador y minificador escrito en Rust, sin las revisiones aisladas y espaciadas que caracterizan a proyectos más grandes como Bun. La información de esta nota proviene únicamente del registro oficial de lanzamientos de oxc en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de oxc, pero equipos locales de frontend que ya usan Vite o proyectos basados en Rolldown están expuestos indirectamente a oxc como dependencia de linting y formateo, y pueden actualizar sin ajustes adicionales, dado que el registro de cambios no reporta rupturas de compatibilidad en ninguna de las tres versiones de hoy.
Entre el lanzamiento programado de Kubernetes 1.37 y dos fallas críticas corregidas en Next.js, esta edición documenta siete desarrollos recientes del ecosistema de programación.
Esta edición documentó siete desarrollos del 24 al 26 de agosto de 2026: el calendario oficial de Kubernetes, que fija hoy la publicación de la versión 1.37.0 con dieciséis mejoras a estable y cambios de ruptura en pods estáticos; dos avisos de seguridad críticos de Next.js, publicados el 25 de agosto, que corrigen fallas de ejecución remota de código sin autenticación en las versiones 16.3.3 y 15.5.24; la versión 1.20260826.1 de Cloudflare workerd, decimoquinta entrega consecutiva de una racha que arrancó el 12 de agosto; las versiones 1.0.81-10 y 1.0.81-11 de GitHub Copilot CLI, publicadas con menos de cuatro horas de diferencia; la versión 8.0.0-rc.8 de Prisma, octava candidata de la versión 8; las versiones 2026.8.13 y 2026.8.14 de mise; y las versiones 1.80.0 de oxlint y 0.65.0 de oxfmt. El hilo que domina la jornada es la tensión entre velocidad de lanzamiento y estabilidad: Kubernetes suma dieciséis funciones nuevas a su superficie estable en el mismo paquete que rompe cómo los pods estáticos referencian secretos, Prisma sigue tocando partes centrales de su API en la octava candidata de una versión 8 sin fecha de lanzamiento estable, y Next.js tuvo que apagar por completo la optimización de imágenes AVIF como parche de emergencia mientras el ecosistema de libheif termina de corregir la causa raíz. Cloudflare Workers y su motor workerd cierran el miércoles como personaje de la semana en esta sección: quince días consecutivos de lanzamientos, del 12 al 26 de agosto, con cambios de código reales en los dos últimos días. Para equipos de desarrollo en Costa Rica, la acción inmediata de hoy es una sola pero urgente: actualizar cualquier aplicación Next.js en producción a la versión 16.3.3 o 15.5.24, en especial si corre sobre servidores Windows o procesa imágenes AVIF sin un proxy externo. El resto de la lista —Kubernetes 1.37, Prisma 8, GitHub Copilot CLI, mise y oxc— queda en fase de observación de rutina, sin cambios que exijan una acción inmediata en producción.