GitLab publicó las versiones 19.3.2, 19.2.6 y 19.1.8 para cerrar una falla de lectura de archivos sin autenticación con la puntuación máxima de CVSS y otra de deserialización insegura con 9.9; rclone corrigió dos fallas de suplantación de autenticación en sus modos S3 y FTP; Traefik cerró cinco avisos de seguridad, el más severo por herencia de identidad NTLM sobre HTTP/3; Cloudflare Wrangler sumó contenedores respaldados por Durable Objects mientras workerd llegó a 31 días de lanzamientos diarios; y pnpm corrigió fallas de sistema de archivos dos días después de sumar soporte de Python y Rust.
Las versiones 19.3.2, 19.2.6 y 19.1.8, publicadas ayer, cierran una falla de recorrido de rutas con la puntuación máxima de CVSS y otra de deserialización insegura que puede exponer credenciales en la edición Enterprise.
GitLab publicó, el 10 de setiembre de 2026, las versiones 19.3.2, 19.2.6 y 19.1.8 de Community Edition y Enterprise Edition, que corrigen dos fallas críticas y una de severidad alta, según el aviso oficial de parches del proyecto. La más severa, CVE-2026-85706, alcanza el máximo posible en la escala CVSS —10.0 sobre 10— y consiste en una falla de recorrido de rutas (path traversal) en la API de comentarios (commits) del repositorio que, combinada con una verificación de autenticación ausente, permite a un atacante sin ninguna credencial leer archivos arbitrarios del servidor, de acuerdo con SecurityOnline. La falla afecta a las versiones 18.7 hasta la 19.1.7, a la rama 19.2 anterior a la 19.2.6 y a la rama 19.3 anterior a la 19.3.2. La segunda falla crítica, CVE-2026-87719, con 9.9 de 10 en CVSS, es una deserialización insegura en el serializador de subscripciones de GraphQL de la edición Enterprise: un atacante puede enviar un argumento de subscripción manipulado para eludir los controles de serialización y forzar una búsqueda de objetos en el servidor, lo que puede exponer la configuración de instancias de Advanced Search y credenciales sensibles, según CyberSecurityNews. GitLab corrigió además, en la misma tanda, una falla de severidad alta que permite a un atacante autenticado ejecutar código remoto importando una exportación de proyecto manipulada. GitLab.com ya corre la versión parchada y los clientes de GitLab Dedicated no necesitan ninguna acción, según el aviso oficial; el matiz que conviene subrayar es que, al cierre de esta edición, la compañía no ha confirmado explotación activa de ninguna de las tres fallas en instalaciones autoadministradas. GitLab recomienda con insistencia que todas las instalaciones autoadministradas —el modelo que usan la mayoría de empresas que corren su propio servidor de control de versiones— actualicen de inmediato a alguna de las tres versiones corregidas. Costa Rica no publica cifras propias de instalaciones autoadministradas de GitLab, pero es una de las plataformas de control de versiones más usadas por bancos y empresas de zonas francas tecnológicas locales que prefieren alojar su propio código antes que depender de un proveedor externo; equipos de infraestructura que administran su propia instancia deberían confirmar hoy mismo la versión que corren, dado que la falla más severa no exige ninguna credencial para explotarse.
Dos fallas de rclone, corregidas en la versión 1.75.1, permitían autenticarse sin credenciales reales contra los servicios S3 y FTP que la herramienta expone, mediante claves de acceso arbitrarias sin secreto verificable.
El catálogo de avisos de seguridad de GitHub revisó y publicó, el 10 de setiembre de 2026, dos fallas críticas de rclone —la herramienta de línea de comandos más usada para sincronizar y respaldar datos contra almacenamiento en la nube— que el proyecto había corregido el 4 de setiembre con la versión 1.75.1. La primera, CVE-2026-88018, con 9.8 de 10 en CVSS, afecta al modo de servidor S3 (rclone serve s3) cuando se activa la bandera --auth-proxy sin la bandera --auth-key: el sistema registra cada identificador de acceso que envía el cliente junto a un secreto vacío, y como una cadena vacía es una llave HMAC válida, cualquier atacante puede firmar solicitudes contra ese secreto y autenticarse sin conocer ninguna credencial real, según el catálogo de avisos de GitHub. La segunda falla, CVE-2026-88044, con 9.1 de 10 en CVSS, afecta a los servidores FTP y S3 que rclone arranca a través de su interfaz de control remoto (RC) con configuración de proxy por servidor: los constructores de esos servidores verifican la configuración global de proxy en lugar de la que se envía en la solicitud, lo que hace que el proxy de autenticación configurado se ignore en silencio. En el caso de FTP, un atacante puede autenticarse como "anonymous" con cualquier contraseña y obtener acceso de lectura, escritura y borrado; en S3, un cliente ya autenticado puede terminar accediendo al sistema de archivos por defecto en lugar del que el proxy debía asignarle, de acuerdo con el mismo catálogo. Ambas fallas exigen una combinación de configuración específica y poco común —activar auth-proxy sin auth-key, o levantar servidores mediante la interfaz RC con proxy por servidor— que no corresponde al uso más extendido de rclone en instalaciones que solo sincronizan archivos de forma local sin exponer ningún servidor; no hay evidencia de explotación activa contra ninguna de las dos fallas al cierre de esta edición. La información de esta nota proviene únicamente del catálogo de avisos de seguridad de GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de rclone, pero la herramienta circula entre equipos de infraestructura y usuarios individuales locales que respaldan datos contra proveedores de nube como S3, Google Drive o Backblaze; quienes exponen rclone como servidor S3 o FTP con proxy de autenticación deberían actualizar hoy mismo a la versión 1.75.1 y revisar si su configuración corresponde a alguno de los dos escenarios descritos.
Traefik, el proxy inverso y controlador de ingreso de Kubernetes desarrollado por Traefik Labs, publicó el 4 de setiembre de 2026 la versión 3.7.13 (y la equivalente 2.11.57 para la rama v2), que corrige cinco avisos de seguridad, según el registro oficial de versiones del proyecto en GitHub. El catálogo de avisos de GitHub revisó y publicó formalmente el lote el 10 de setiembre. El más severo de los cinco, CVE-2026-88007, con 9.1 de 10 en la escala CVSS versión 4, describe una falla en la implementación de HTTP/3 de Traefik: el punto de entrada HTTP/3 reutiliza la cadena de manejo de HTTPS pero omite la llamada que aísla el transporte por conexión (service.AddTransportOnContext), lo que impide que el enrutador Kerberos (kerberosRoundTripper) separe las conexiones por cliente. El resultado, según el aviso, es que un cliente HTTP/3 sin ninguna relación con una conexión previa puede reutilizar la conexión de backend ya autenticada de otra persona y heredar su identidad frente a sistemas que usan autenticación NTLM o Kerberos con conexiones persistentes. La falla afecta a Traefik v2 entre las versiones 2.11.0 y 2.11.56, y a v3 entre la 3.0.0 y la 3.7.12, según el mismo aviso. El matiz que acota el riesgo real: la explotación exige que el backend protegido use específicamente autenticación NTLM o Negotiate/Kerberos sobre conexiones persistentes detrás de un enrutamiento HTTP/3 —una combinación poco común fuera de entornos corporativos que todavía dependen de autenticación de Windows integrada—, no cualquier despliegue de Traefik expuesto a internet. Los otros cuatro avisos corregidos en la misma versión no alcanzan severidad crítica según el catálogo de GitHub. La información de esta nota combina el catálogo de avisos de seguridad de GitHub y el registro oficial de versiones de Traefik, sin cobertura de prensa especializada adicional al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Traefik, pero es uno de los controladores de ingreso más usados por equipos de DevOps locales que operan clústeres de Kubernetes, incluidos bancos y empresas de zonas francas tecnológicas; equipos que exponen backends con autenticación NTLM o Kerberos detrás de Traefik con HTTP/3 habilitado deberían actualizar hoy mismo a la versión 3.7.13 o 2.11.57.
cat /feed/devopscloudflareworkers.md
La versión 4.131.0 de Wrangler, publicada ayer, suma administración de contenedores respaldados por Durable Objects y corrige una falla de seguridad en su dependencia shell-quote; horas después, workerd llegó a 31 días de lanzamientos diarios.
> Cloudflare publicó, el 10 de setiembre de 2026 a las 15:20 UTC, la versión 4.131.0 de Wrangler, la herramienta de línea de comandos para desplegar Cloudflare Workers, que suma soporte para el parámetro scheduling_policy: "durable_object" en la configuración de contenedores, lo que permite administrar aplicaciones respaldadas por espacios de nombres de Durable Objects con despliegues idempotentes, según el registro oficial de versiones del proyecto en GitHub. La misma entrega retira los comandos de vista previa wrangler preview settings, que estaban en beta privada, corrige la detección de Workers de módulo nombrados frente a los Service Workers heredados, y actualiza la dependencia shell-quote a la versión 1.9.0 o superior para cerrar una vulnerabilidad de denegación de servicio por expresiones regulares (ReDoS) y de escape de comandos que afectaba las operaciones de wrangler pages dev, de acuerdo con la misma fuente.
> Horas después, a la 01:05 UTC del 11 de setiembre, Cloudflare publicó la versión 1.20260911.1 de workerd, el motor de ejecución de Cloudflare Workers, que mejora los mensajes de error para los Workers de Python que usan aleatoriedad (randomness) a nivel superior del módulo, refactoriza los reintentos de Durable Objects y suma soporte de net.BoundSocket al módulo node:net, según el mismo registro. Es la trigésimo primera entrega consecutiva de la racha diaria de lanzamientos de workerd, sostenida sin interrupciones desde el 12 de agosto. A diferencia de la corrección de seguridad de Wrangler —un cambio de fondo verificable en una dependencia con historial de vulnerabilidades—, la entrega de hoy de workerd es, como la mayoría de la racha, trabajo incremental de plataforma sin efecto inmediato para Workers ya desplegados.
> La información de esta nota proviene únicamente de los registros oficiales de versiones de Wrangler y 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 despliegan sobre la plataforma deberían revisar si su flujo de wrangler pages dev depende de shell-quote, dado que la versión anterior arrastraba una vulnerabilidad de escape de comandos; quienes ya usan contenedores en Workers pueden evaluar esta semana la nueva política de programación respaldada por Durable Objects.
El equipo de pnpm publicó, el 10 de setiembre de 2026 a las 17:00 UTC, la versión 12.4.1 de su gestor de paquetes, que corrige que las instalaciones fallaran con el error "Operation not permitted" en sistemas de archivos que rechazan enlaces duros (hard links) o clones de copia en escritura (copy-on-write) —una situación habitual en Android y en contenedores sin privilegios de root—, según el registro oficial de versiones del proyecto en GitHub. La misma entrega corrige que el modo nodeLinker: hoisted reimportara paquetes ya instalados sin necesidad, agiliza las instalaciones repetidas al optimizar la verificación del almacén (store) local, resuelve errores de "Invalid cross-device link" durante construcciones (builds) de Docker, y hace que los scripts de construcción vuelvan a ejecutarse cuando las entradas de caché de efectos secundarios no contienen archivos. La corrección llega dos días después de la versión 12.4.0, publicada el 8 de setiembre, que sumó la posibilidad de administrar dependencias de Python y de crates de Rust dentro del mismo espacio de trabajo que ya maneja paquetes de npm —la función que esta sección documentó como la nota principal de esa edición—. El mismo 10 de setiembre, el equipo publicó además la versión 0.1.0-alpha.11 de pnpr, un registro de paquetes experimental y separado del CLI principal que sirve simultáneamente paquetes de npm, Cargo y PyPI desde una sola instancia, con soporte de alojamiento de imágenes de contenedor mediante la API de distribución OCI, publicación multiecosistema en una sola transacción e inicio de sesión mediante OIDC en el navegador, según el mismo registro. Que el equipo lance en la misma semana el soporte de instalación multiecosistema en el CLI y un registro propio que sirve esos mismos tres ecosistemas sugiere una apuesta más amplia por convertir a pnpm en la capa de paquetes de facto para proyectos que combinan JavaScript con Python o Rust, aunque pnpr sigue en una fase alfa temprana sin garantías de estabilidad. La información de esta nota proviene únicamente de los registros oficiales de versiones de pnpm y pnpr en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de pnpm, pero el gestor gana terreno entre equipos de desarrollo locales de zonas francas tecnológicas que corren proyectos con dependencias mixtas de JavaScript y Python; equipos que ya instalaron la versión 12.4.0 en sistemas Android o contenedores sin privilegios de root deberían actualizar hoy mismo a la 12.4.1 para evitar el error de permisos.