PostgreSQL corrigió una falla de decodificación lógica que permite ejecutar código con los permisos del servidor, calificada con 7.2 de 10 en la escala CVSS y corregida desde el 13 de agosto; pnpm llevó a su rama de mantenimiento 11.x el mismo blindaje contra ataques a la cadena de suministro que había sumado la semana pasada en la rama 12, y corrigió una fuga de credenciales en los registros de reintento; Supabase CLI cerró una fuga de rutas en sus plantillas de correo de autenticación local; Vite sumó integración con devtools en la beta 8.3.0 rumbo a Rolldown; y Cloudflare workerd llegó a 27 días consecutivos de lanzamientos.
El PostgreSQL Global Development Group corrigió, el 13 de agosto de 2026, la vulnerabilidad CVE-2026-6471 —con un puntaje de 7.2 en la escala CVSS— en el mecanismo de decodificación lógica (logical decoding) de PostgreSQL, según el aviso oficial de seguridad del proyecto. La falla, presente sin corregir desde que la decodificación lógica se introdujo en la versión 9.4 en 2014, permite que una cuenta sin privilegios de superusuario pero con el atributo REPLICATION elija un módulo de salida (output plugin) arbitrario para cargarlo con dlopen(), lo que en la práctica ejecuta código con los permisos de la cuenta del sistema operativo que corre el servidor, de acuerdo con el mismo aviso. El parche, incluido en las versiones 18.6, 17.11, 16.15, 15.19 y 14.24, agrega el parámetro de servidor output_plugin_libraries, que limita qué librerías pueden cargarse como módulos de salida y que por defecto solo permite pgoutput y test_decoding. El medio de seguridad TheHackerNews retomó el caso el 4 de setiembre, doce años después de que el mecanismo vulnerable llegara a producción, y TheHackerWire lo documentó bajo el nombre con el que circula entre investigadores, "PostGREShell". El puntaje de 7.2 conviene matizarlo: la explotación exige dos condiciones que no se cumplen en toda instalación —que la cuenta atacante tenga el atributo REPLICATION, algo que la mayoría de aplicaciones no otorga a usuarios que no sean de confianza, y que el servidor corra con wal_level = logical, una configuración que no viene activada por defecto y que solo instalaciones con replicación lógica activa, por ejemplo hacia un data warehouse, suelen habilitar. Al 4 de setiembre, la falla seguía ausente del catálogo de vulnerabilidades explotadas de CISA y TheHackerNews no había encontrado código de prueba de concepto público, según su propia cobertura. Costa Rica no publica cifras propias de despliegues de PostgreSQL, pero es una de las bases de datos de código abierto más usadas por bancos y empresas de zonas francas tecnológicas locales; equipos que habilitaron wal_level = logical para sincronizar datos hacia otro sistema y que otorgan el atributo REPLICATION a cuentas de aplicación deberían confirmar esta semana que ya corren una de las cinco versiones parchadas.
La versión 11.26.0, publicada anoche, lleva a la rama 11 las banderas de confianza que la rama 12 sumó la semana pasada y corrige una fuga de credenciales en los registros de reintento.
El equipo de pnpm publicó, el 6 de setiembre de 2026 a las 23:50 UTC, la versión 11.26.0 de su gestor de paquetes, que lleva a la rama de mantenimiento 11.x las banderas trust-lockfile para los comandos pnpm remove y pnpm update que la rama 12 había sumado la semana pasada, según el registro oficial de versiones del proyecto en GitHub. La misma entrega corrige un problema de exposición de datos: los registros de errores de descarga y de reintentos de descarga de paquetes (tarball) dejaban de ocultar credenciales, cadenas de consulta y fragmentos incluidos en la URL, lo que podía filtrar secretos hacia archivos de registro o salidas de integración continua, de acuerdo con la misma fuente. La versión suma además el comando pnpm change check para validar versiones de paquete en integración continua y la posibilidad de que los catálogos (catalogs) resuelvan dependencias de espacio de trabajo (workspace) a través del protocolo workspace:. Es la tercera entrega en cinco días que esta sección sigue en pnpm: la rama 12.3 sumó las banderas de confianza el miércoles 2 de setiembre, una regresión de esa misma versión rompió las instalaciones automáticas sobre Vercel —corregida con los parches 12.3.3 y 12.3.4 el viernes 4 de setiembre, según la edición de ayer de esta sección—, y anoche la rama de mantenimiento 11.x recibió el mismo blindaje contra ataques a la cadena de suministro, además de la corrección a la fuga de credenciales en los registros de reintento. Equipos que se quedaron en la rama 11.x por no migrar a la 12 —que introdujo cambios que rompen compatibilidad— pasaron cuatro días sin el mismo nivel de protección que ya tenía la rama activa. La información de esta nota proviene únicamente del registro oficial de versiones de pnpm en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de instalaciones de pnpm por rama, pero equipos de desarrollo locales de zonas francas tecnológicas que aún corren la rama 11.x por no haber migrado a la 12 deberían actualizar esta semana a la versión 11.26.0 para cerrar la fuga de credenciales en los registros de reintento.
El equipo de Supabase publicó, el 7 de setiembre de 2026 a las 11:14 UTC, la versión 2.117.0-beta.23 de su interfaz de línea de comandos (CLI), que corrige un error identificado internamente como CLI-2320: el parámetro content_path, usado para apuntar al contenido de las plantillas de correo de autenticación durante el desarrollo local, podía señalar a archivos fuera de la raíz del proyecto antes de esta versión, según el registro oficial de cambios del proyecto en GitHub. La misma entrega corrige además el mensaje de error 404 de la configuración y alinea los errores de carga del comando push. Horas antes, la versión 2.117.0-beta.22, publicada a las 07:57 UTC, había corregido el manejo de objetos gestionados por extensiones de PostgreSQL durante la sincronización declarativa del esquema (declarative sync), evitando que el CLI intentara eliminar objetos que una extensión ya administraba. Las tres entregas del fin de semana —la beta.21 del sábado, que sumó control de exposición y la bandera --instances para las funciones locales (workers); la beta.22 del domingo por la mañana; y la beta.23 de esta mañana— forman parte del ciclo de beta hacia la versión estable 2.117.0. El error de confinamiento de rutas que corrige la beta.23 solo afecta al entorno de desarrollo local que levanta supabase start, no a los proyectos ya desplegados en Supabase Cloud, lo que limita el impacto práctico a equipos que personalizan las plantillas de correo mientras desarrollan en su propia máquina. La información de esta nota proviene únicamente del registro oficial de cambios de Supabase 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 Supabase, pero la plataforma gana terreno entre startups y equipos de desarrollo locales que buscan una alternativa de código abierto a Firebase sobre PostgreSQL; equipos que personalizan plantillas de correo de autenticación en desarrollo local deberían actualizar a la beta.23 o esperar la próxima versión estable antes de exponer ese flujo a un entorno compartido.
El equipo de Vite publicó, el 7 de setiembre de 2026 a las 11:38 UTC, la versión 8.3.0-beta.1, que habilita la integración del servidor de desarrollo con las herramientas de depuración (devtools) del navegador y corrige seis fallas: el mantenimiento de los marcadores de posición de hash (hash placeholders) sin modificar dentro del gancho resolveFileUrl, el registro correcto de la entrega de contenido en los reportes del cliente durante el desarrollo empaquetado, la resolución de la raíz real del paquete más cercano cuando existen archivos package.json anidados, un error en la extensión de atajos de teclado (shortcuts) y el fin de la inserción automática de objetivos de precarga (preload) dentro del procesamiento de HTML, según el registro oficial de versiones del proyecto en GitHub. La entrega llega cinco días después de la beta.0, publicada el 2 de setiembre, que sumó soporte de opciones de vigilancia (watch) para el empaquetador Rolldown, los métodos de ciclo de vida closeServer y closePreviewServer, una opción de configuración tsconfig de nivel superior y minificación de etiquetas de estilo CSS, de acuerdo con la misma fuente. El ciclo de beta 8.3 avanza dentro de la transición de Vite hacia Rolldown, el empaquetador escrito en Rust que el proyecto adoptó como base de Vite 8 para reemplazar gradualmente a esbuild y Rollup. Astro ya documentó el efecto de ese cambio: su versión 7, publicada en agosto sobre Vite 8 y Rolldown, reportó construcciones hasta 61% más rápidas que su versión anterior, según la cobertura de InfoQ sobre ese lanzamiento. Que Vite dedique esta beta a integrar sus propias herramientas de depuración con el servidor de desarrollo, en lugar de sumar funciones exclusivas de Rolldown, sugiere que el proyecto trata la migración del empaquetador y la experiencia de desarrollo como dos frentes de trabajo separados dentro del mismo ciclo de versión. Costa Rica no publica cifras propias de adopción de Vite, pero es la herramienta de desarrollo más común entre equipos de frontend locales que trabajan con Vue, React o Svelte; equipos que ya siguen el ciclo de beta de Vite 8 pueden probar la integración de devtools de esta versión, aunque conviene esperar a la versión estable antes de adoptarla en producción.
— La versión 8.3.0-beta.1, publicada esta mañana, habilita la integración del servidor de desarrollo con las herramientas de depuración del navegador, dentro del ciclo de beta que prepara a Vite 8 sobre Rolldown.
cat /feed/devopscloudflareworkers.md
La versión 1.20260907.1, publicada a la 01:11 UTC, extiende a 27 la racha de entregas diarias consecutivas del motor de Cloudflare Workers, sin que el registro público detalle cambios de comportamiento.
> Cloudflare publicó, el 7 de setiembre de 2026 a la 01:11 UTC, la versión 1.20260907.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos del proyecto en GitHub. Es la vigésimo séptima entrega consecutiva de la racha diaria de lanzamientos de Cloudflare workerd, sostenida sin interrupciones desde el 12 de agosto, de acuerdo con el mismo registro.
> A diferencia de la entrega del jueves, que sumó soporte de thread sanitizer en macOS y una función nueva de trazas, o de la del sábado, que corrió un día hacia adelante la fecha máxima de compatibilidad del runtime, el registro público de la versión de hoy no incluye una descripción de cambios más allá de la comparación de código entre ambas versiones: un único cambio interno, según el historial de confirmaciones del repositorio, sin notas que expliquen su efecto en el comportamiento del runtime. Es la entrega más opaca de la racha desde que esta sección la sigue, aunque eso no equivale a evidencia de que no haya cambios de fondo, sino a que el equipo de Cloudflare no los documentó públicamente esta vez.
> 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, dado que no hay cambios de comportamiento documentados.
Entre la falla que PostgreSQL corrigió en su decodificación lógica y el blindaje que pnpm llevó a su rama 11, esta edición documenta cinco desarrollos recientes del ecosistema de programación.
Esta edición documentó cinco desarrollos del 13 de agosto al 7 de setiembre de 2026: la vulnerabilidad CVE-2026-6471 en la decodificación lógica de PostgreSQL, con un puntaje de 7.2 en la escala CVSS y corregida desde el 13 de agosto en cinco ramas de la base de datos; la versión 11.26.0 de pnpm, que llevó a su rama de mantenimiento 11.x el mismo blindaje contra ataques a la cadena de suministro que la rama 12.3 sumó la semana pasada y corrigió una fuga de credenciales en los registros de reintento; la versión 2.117.0-beta.23 de Supabase CLI, que confinó a la raíz del proyecto el parámetro de las plantillas de correo de autenticación local; la versión 8.3.0-beta.1 de Vite, que sumó integración con devtools dentro del ciclo de beta hacia Rolldown; y la versión 1.20260907.1 de Cloudflare workerd, la vigésimo séptima entrega consecutiva de su racha diaria. El hilo que esta sección viene siguiendo en pnpm desde el miércoles pasado —las banderas de confianza de la rama 12.3, la regresión que rompió instalaciones sobre Vercel y sus parches— llegó hoy a la rama de mantenimiento 11.x, la que usan los equipos que no migraron a la versión con cambios que rompen compatibilidad: durante cuatro días, esos equipos corrieron sin el mismo blindaje que ya tenía la rama activa. La falla de PostgreSQL, aunque parchada desde agosto, ilustra un patrón parecido: una relación de confianza —aquí, entre el atributo REPLICATION y el mecanismo de decodificación lógica— que una validación incompleta dejó abierta durante doce años sin que nadie la explotara públicamente, según la información disponible al cierre de esta edición. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición combina tres frentes: quien administra PostgreSQL con wal_level = logical y otorga el atributo REPLICATION a cuentas de aplicación debe confirmar que ya corre una versión parchada; quien se quedó en la rama 11.x de pnpm debe actualizar a la 11.26.0 esta semana; y quien personaliza plantillas de correo de autenticación en Supabase CLI durante el desarrollo local debe actualizar a la beta.23. El resto de la lista —Vite y Cloudflare workerd— queda en fase de observación de rutina.