El proyecto aws-efs-csi-driver corrigió una falla de severidad alta que permitía el borrado no autorizado de datos en volúmenes de Kubernetes con Amazon EFS, calificada con 8.7 de 10 en la escala CVSS; GitHub Copilot CLI sumó la opción de desactivar el sandbox a mitad de sesión y soporte para el modelo GPT-6 Astra; Bun publicó la versión 1.4.1 con HTTP/2 nativo en su servidor y escritura de respuestas directo a disco; Cloudflare workerd llegó a 25 días consecutivos de lanzamientos; GitHub Actions sumó una API para anticipar el fin de soporte de sus ejecutores y acceso de solo lectura a las alertas de Dependabot; y Terraform corrigió un bloqueo indefinido de su CLI.
El proyecto kubernetes-sigs/aws-efs-csi-driver publicó, el 4 de setiembre de 2026, el aviso de seguridad GHSA-5mrv-3w42-4fhg para CVE-2026-85781, una falla de severidad alta —8.7 de 10 en la escala CVSS— en el mecanismo de borrado de volúmenes del controlador CSI que Amazon Elastic File System (EFS) usa dentro de clústeres de Kubernetes, según el aviso oficial publicado en GitHub. El controlador no valida que un punto de acceso (access point) de EFS pertenezca en realidad al sistema de archivos que dice representar: un usuario autenticado con permisos para crear volúmenes persistentes (PersistentVolume) puede construir uno que combine el punto de acceso de un sistema de archivos con el identificador de otro distinto y, al eliminarlo, provocar el borrado recursivo de directorios en un sistema de archivos ajeno, de acuerdo con la misma fuente. Las versiones 3.4.0 y anteriores quedan expuestas; la versión 3.4.1 corrige la falla validando la propiedad del punto de acceso durante la operación DeleteVolume, según el registro de cambios del repositorio. El aviso detalla, sin embargo, que el ataque exige varias condiciones simultáneas que no se cumplen en toda instalación: la bandera --delete-access-point-root-dir=true debe estar activada —no es el comportamiento por defecto—, quien ataca debe tener permiso para crear o modificar volúmenes persistentes, la política de reclamo del volumen debe ser Delete y el controlador debe tener acceso al sistema de archivos víctima, según el mismo aviso de GitHub. Esa lista de precondiciones matiza el puntaje de 8.7: no es una puerta abierta por defecto, sino un riesgo concentrado en clústeres que ya activaron una opción no estándar del controlador, un patrón que TheHackerWire y el rastreador de amenazas OffSeq describen de forma similar en su cobertura, sin que ninguna de las dos fuentes reporte explotación activa de CVE-2026-85781 al cierre de esta edición. Costa Rica no publica cifras propias de despliegues de Amazon EFS sobre Kubernetes, pero bancos y empresas de zonas francas tecnológicas que corren cargas en Amazon EKS con almacenamiento compartido en EFS son la audiencia directa de este aviso; equipos que activaron --delete-access-point-root-dir=true deberían confirmar esta semana que ya corren la versión 3.4.1 del controlador y revisar qué cuentas tienen permiso para crear volúmenes persistentes en sus clústeres.
GitHub publicó, el 4 de setiembre de 2026, las versiones 1.0.84-0 (21:15 UTC) y 1.0.84-1 (23:20 UTC) de Copilot CLI, que agregan la posibilidad de desactivar el aislamiento de sandbox a mitad de una sesión mediante un aviso de excepción (bypass prompt) que la persona usuaria debe aprobar de forma explícita, según el registro oficial de versiones del proyecto en GitHub. La misma entrega corrige el comportamiento de bloqueo del sandbox en PowerShell, resuelve un problema de manejo de credenciales de GitHub cuando la sesión usa varias cuentas, corrige la visibilidad del comando /rubber-duck tras una actualización de modelos, actualiza las rutas de caché de herramientas de desarrollo dentro del sandbox y mejora las operaciones de Git en sandboxes sobre Windows. La versión 1.0.84-1 suma, además, soporte para el modelo GPT-6 Astra como una opción más dentro de Copilot CLI. La opción de apagar el sandbox a mitad de sesión llega apenas un día después de que esta sección documentara que la versión 1.0.83-5 restringió por defecto el acceso a localhost desde ese mismo sandbox: el endurecimiento de esta semana —forceLoginOrgs el lunes, la salida de red limitada a un proxy el martes, el bloqueo de localhost el jueves— ahora convive con una vía explícita para desactivarlo, siempre que alguien apruebe esa excepción durante la sesión. Ninguna fuente consultada documenta abuso de esa vía de excepción, pero introduce una tensión de diseño: cada capa de aislamiento que Copilot CLI cierra por defecto necesita, en algún punto, una puerta para el caso legítimo que ese aislamiento bloquearía por error. La información de esta nota proviene únicamente del registro oficial de versiones 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 Copilot CLI, pero bancos y empresas de zonas francas tecnológicas que ya exigen sandbox aislado para sus agentes de código deberían definir esta semana quién dentro del equipo queda autorizado a aprobar el aviso de excepción antes de habilitarlo en sus flujos de trabajo.
La versión 1.4.1, publicada el 4 de setiembre, estrena soporte de HTTP/2 en Bun.serve(), escritura de respuestas directo a disco y espacios de trabajo autocontenidos, entre más de un centenar de correcciones.
El equipo de Bun publicó, el 4 de setiembre de 2026, la versión 1.4.1 del entorno de ejecución de JavaScript, que agrega soporte de HTTP/2 dentro de Bun.serve(), la posibilidad de que Bun.write() transmita el cuerpo de una respuesta directo a disco sin cargarlo entero en memoria, espacios de trabajo (workspaces) de node_modules autocontenidos, las banderas bun install --offline y --prefer-offline, la función crypto.argon2 y la posibilidad de pausar y reanudar conexiones WebSocket con los métodos pause() y resume(), según el registro oficial de versiones del proyecto en GitHub y el blog oficial de Bun. La misma entrega redujo cerca de 1 MB el tamaño del binario de lanzamiento y reportó lecturas y escrituras de Buffer hasta 9 veces más rápidas que en la versión anterior, de acuerdo con las mismas fuentes. La lista de cambios llega dentro del ciclo de estabilización que siguió a Bun 1.4, la versión que en agosto reescribió partes centrales del runtime en Rust y generó advertencias sobre cambios que rompen compatibilidad para quienes migraran versiones mayores. Que la 1.4.1 dedique buena parte de su esfuerzo a completar funciones que Node.js y Deno ya ofrecen —streaming a disco, HTTP/2 nativo, instalación sin conexión— confirma que la competencia entre los tres entornos de ejecución de JavaScript se libra hoy en la paridad de funciones básicas de servidor, más que en funciones exclusivas de un solo runtime. Costa Rica no publica cifras propias de adopción de Bun, pero el runtime gana terreno entre equipos de desarrollo locales de zonas francas tecnológicas que buscan alternativas más rápidas a Node.js para servicios backend y herramientas de línea de comandos; equipos que ya corren Bun en producción pueden evaluar esta semana el soporte nuevo de HTTP/2 en Bun.serve() para servicios que hoy dependen de un proxy externo únicamente para ese protocolo.
Cloudflare publicó, el 5 de setiembre de 2026, la versión 1.20260905.1 de workerd, el motor de ejecución de Cloudflare Workers, con cambios que incluyen soporte ampliado de thread sanitizer para macOS, la preservación del estado de entrega de rechazos (rejection delivery state) de una promesa cuando esta se sustituye por otra dentro del runtime, y la función span.getActiveSpan, identificada internamente como WO-1582, para leer la traza activa dentro del código de instrumentación, según el registro oficial de lanzamientos del proyecto en GitHub. Es la vigésimo quinta entrega consecutiva de la racha diaria de lanzamientos de Cloudflare workerd, sostenida sin interrupciones desde el 12 de agosto, según el mismo registro. A diferencia de la entrega del 4 de setiembre, que revirtió dos cambios recientes, la de hoy no deshace ningún trabajo previo: suma soporte de pruebas y observabilidad sin tocar el comportamiento de ejecución de las aplicaciones ya desplegadas sobre la plataforma. 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: los cambios de hoy son trabajo de instrumentación y pruebas, sin efecto en aplicaciones ya desplegadas.
— La versión 1.20260905.1, publicada hoy, suma soporte de thread sanitizer en macOS y una función nueva de trazas, en la vigésimo quinta entrega consecutiva de la racha diaria del proyecto.
cat /feed/devopsgithubactions.md
El registro de cambios de GitHub del 3 de setiembre agrega una API para consultar el fin de soporte de cada versión de ejecutor y un permiso de solo lectura para que los flujos de trabajo lean alertas de Dependabot.
> GitHub publicó, el 3 de setiembre de 2026, dos cambios en GitHub Actions: una API REST nueva que devuelve la fecha en que termina el registro y el soporte en tiempo de ejecución de una versión específica de ejecutor (runner), lo que permite planificar actualizaciones antes de que una versión quede obsoleta; y un permiso nuevo, vulnerability-alerts, para el token GITHUB_TOKEN, que da a un flujo de trabajo acceso de solo lectura a las alertas de Dependabot de un repositorio, con los valores read y none disponibles para aplicar el principio de mínimo privilegio, según el registro oficial de cambios de GitHub.
> El permiso vulnerability-alerts resuelve un problema práctico: antes de este cambio, un flujo de trabajo que necesitaba leer el estado de las alertas de Dependabot —por ejemplo, para bloquear un despliegue si existe una alerta crítica sin resolver— tenía que autenticarse con un token personal con permisos más amplios que los que GITHUB_TOKEN ofrecía, una práctica que la propia guía de seguridad de GitHub Actions desaconseja. La nueva API de fin de soporte de ejecutores, por su parte, atiende a organizaciones que administran sus propios ejecutores autoalojados (self-hosted runners) y necesitan saber con anticipación cuándo una versión deja de recibir actualizaciones.
> La información de esta nota proviene únicamente del registro oficial de cambios de GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de GitHub Actions, pero es la plataforma de integración continua más común entre equipos de desarrollo locales de zonas francas tecnológicas y bancos; equipos que ya usan GITHUB_TOKEN en sus flujos de trabajo pueden adoptar esta semana el permiso vulnerability-alerts para evitar tokens personales de alcance más amplio del necesario.
HashiCorp publicó, el 2 de setiembre de 2026, la versión 1.16.1 de Terraform, un parche que corrige cinco fallas puntuales: un bloqueo indefinido de la interfaz de línea de comandos cuando una tarea de ejecución (run task) fallaba con evaluaciones de política todavía pendientes; un error en bloques de importación que usan for_each o count; un caso que provocaba un cierre abrupto (panic) del comando terraform state show; una validación incompleta del archivo de bloqueo de proveedores dentro de stacks; y un ajuste al orden de creación antes de destrucción (create-before-destroy), según el registro oficial de versiones del proyecto en GitHub. El parche llega seis días después de la versión 1.16.0, que agregó almacenamiento privado de datos de proveedores entre plan y apply, un bloque terraform_data para valores efímeros o sensibles y soporte del formato Mermaid para terraform graph. Que el primer bloqueo corregido hoy ocurriera específicamente cuando una tarea de ejecución fallaba con políticas pendientes de evaluar señala un punto de fricción real para equipos que integran controles de política —como Sentinel u Open Policy Agent— directamente en su flujo de despliegue: una falla de política mal manejada terminaba, hasta esta versión, congelando la terminal en lugar de devolver el control a quien ejecuta el comando. La información de esta nota proviene únicamente del registro oficial de versiones de Terraform en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de Terraform, pero es la herramienta de infraestructura como código más común entre equipos de desarrollo locales de bancos y zonas francas tecnológicas que administran infraestructura en AWS, Azure o Google Cloud; equipos que integran controles de política en su flujo de aprobación deberían actualizar a la 1.16.1 esta semana para evitar el bloqueo corregido hoy.
Entre la falla que expone a Kubernetes con Amazon EFS y el debut de HTTP/2 nativo en Bun, esta edición documenta seis desarrollos recientes del ecosistema de programación.
Esta edición documentó seis desarrollos del 2 al 5 de setiembre de 2026: la vulnerabilidad CVE-2026-85781 en el driver CSI de Amazon EFS para Kubernetes, con un puntaje de 8.7 en la escala CVSS y corregida en la versión 3.4.1; las versiones 1.0.84-0 y 1.0.84-1 de GitHub Copilot CLI, que permiten desactivar el sandbox a mitad de sesión; la versión 1.4.1 de Bun, con soporte de HTTP/2 nativo en Bun.serve() y escritura de respuestas directo a disco; la versión 1.20260905.1 de Cloudflare workerd, la vigésimo quinta entrega consecutiva de su racha diaria; los cambios del 3 de setiembre en GitHub Actions, con una API de fin de soporte de ejecutores y un permiso de solo lectura para alertas de Dependabot; y la versión 1.16.1 de Terraform, que corrigió un bloqueo indefinido de su CLI. El hilo que esta sección viene siguiendo desde el lunes en torno al endurecimiento del sandbox de Copilot CLI cerró la semana laboral el jueves con el bloqueo de localhost por defecto, y hoy sumó una vía explícita para desactivar ese mismo sandbox a mitad de sesión: cada capa de aislamiento nueva conserva, en algún punto, una puerta de excepción para el caso legítimo que bloquearía por error. La falla en el driver CSI de Amazon EFS repite, con otro componente, la misma lección que esta sección documentó ayer con Red Hat Advanced Cluster Management: una relación de confianza dentro de un clúster —aquí, entre volúmenes persistentes y los puntos de acceso de un sistema de archivos compartido— vuelve a ser el eslabón que una validación incompleta puede romper. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición es doble: quien activó la bandera --delete-access-point-root-dir=true en el driver CSI de Amazon EFS debe confirmar que ya corre la versión 3.4.1, y quien administra flujos de trabajo de GitHub Actions puede adoptar esta semana el permiso vulnerability-alerts para dejar de usar tokens personales de alcance más amplio del necesario. El resto de la lista —Copilot CLI, Bun, Cloudflare workerd y Terraform— queda en fase de observación de rutina.