Next.js y Astro corrigieron, a fines de agosto, tres fallas críticas de ejecución remota de código ligadas a la misma librería de imágenes AVIF, y GitHub las catalogó formalmente el 8 de setiembre junto a otras cinco fallas críticas represadas en Predis, CakePHP, GitPython, MapLibre GL y Microsoft QUIC; Node.js publicó la versión 24.21.0 de su rama Krypton con soporte de OpenSSL 3.5.8; Cloudflare Wrangler sumó observabilidad de contenedores y workerd llegó a 29 días de lanzamientos diarios; y Supabase CLI estrenó, en modo experimental, los comandos stack start y stack stop.
Una falla en la librería libheif, usada por Sharp para optimizar imágenes AVIF, permitía ejecutar código sin autenticación en Next.js y Astro; ambos proyectos ya publicaron parches, pero GitHub apenas los catalogó como críticos el 8 de setiembre.
Vercel corrigió, el 25 de agosto de 2026, dos vulnerabilidades críticas de ejecución remota de código en Next.js sin necesidad de autenticación: la identificada como GHSA-2xp9-vwfh-vxw4, con 9.5 de 10 en la escala CVSS, que se dispara al optimizar archivos AVIF mediante una falla de la librería libheif integrada en Sharp; y la CVE-2026-75604, con 9.0 de 10, que afecta a servidores desplegados sobre Windows y permite recorrer rutas de archivo fuera del directorio restringido, según el catálogo de avisos de seguridad de GitHub. Ambas fallas, reportadas por los investigadores evolutionstorm y B0RI, afectan a las versiones de Next.js entre la 13.4.0 y la 15.5.23 y entre la 16.0.0 y la 16.3.2, y se corrigieron en las versiones 15.5.24 y 16.3.3. Dos días después, el 27 de agosto, el equipo de Astro publicó la versión 7.2.8, que corrige la misma clase de falla —identificada como GHSA-26w7-cxv4-gfx2, con 9.8 de 10 en la escala CVSS y crédito del investigador cn-panda— actualizando su dependencia de Sharp a la versión 0.35.4 o superior. El origen común de las tres fallas es una vulnerabilidad de lectura y escritura fuera de límites (CWE-125 y CWE-787) en libheif, la librería en C que decodifica archivos AVIF, documentada por separado bajo el identificador GHSA-g89c-p67h-r497. Cualquier aplicación que use Sharp —la librería de procesamiento de imágenes más común en el ecosistema de Node.js— para optimizar archivos AVIF subidos por usuarios queda expuesta hasta actualizar esa dependencia, sin importar el framework que la envuelva; que Next.js y Astro compartieran el mismo problema con nueve días de diferencia entre sus parches ilustra ese riesgo compartido. GitHub revisó y publicó formalmente los tres avisos en su catálogo de seguridad hasta el 8 de setiembre, entre dos y trece días después de que cada proyecto ya hubiera liberado su corrección, según el mismo catálogo; hasta esa fecha, herramientas que dependen de avisos revisados por GitHub —como Dependabot o npm audit en su modo estricto— no habían alertado del problema pese a que el código vulnerable llevaba semanas en producción en instalaciones sin actualizar. Costa Rica no publica cifras propias de despliegues de Next.js o Astro, pero Next.js es uno de los frameworks de frontend más usados por agencias digitales y equipos de zonas francas tecnológicas locales que despliegan sobre Vercel; equipos que optimizan imágenes subidas por usuarios con Sharp, en cualquiera de los dos frameworks, deberían confirmar hoy mismo que corren una versión posterior a los parches de agosto.
El catálogo de avisos de seguridad de GitHub publicó, el 8 de setiembre de 2026, ocho avisos de severidad crítica cuya fecha de revisión coincide en el mismo día, pese a que sus fechas de divulgación original se reparten entre el 10 y el 27 de agosto, según el propio catálogo. Entre los seis avisos que no involucran a Next.js ni Astro —cubiertos por separado en esta edición—: Predis, el cliente de Redis para PHP, corrigió con la versión 3.3.0 la falla CVE-2026-84372 (9.8 de 10 en CVSS), que permite inyectar comandos arbitrarios de Redis mediante secuencias CRLF mal neutralizadas en operaciones en tubería (pipeline) sobre conexiones de clúster o réplica, con capacidad de ejecutar FLUSHDB o robar llaves sin autenticación; CakePHP corrigió la CVE-2026-77635 (9.2), una inyección SQL en el método FunctionsBuilder::jsonValue() con el controlador de PostgreSQL, en las versiones 5.3.7, 5.2.15 y 5.1.10; GitPython corrigió la CVE-2026-78676 (9.3), que permite ejecutar código arbitrario cuando el propio proceso de reescritura de configuración de GitPython corrompe un valor multilínea legítimo hasta convertirlo en una directiva core.hooksPath maliciosa, en la versión 3.1.59; MapLibre GL JS corrigió la CVE-2026-85061 (10.0), un cruce de sitios sin necesidad de clic —el saneador recorre los atributos de un elemento mientras los elimina, lo que salta la revisión del atributo siguiente en secuencias como onload/ontoggle—, en la versión 6.4.1; y Microsoft corrigió la CVE-2026-62815 (10.0) en su librería QUIC, un uso de memoria después de liberada (use-after-free) explotable de forma remota y sin autenticación, en las versiones 2.5.10 y 2.4.19. El patrón que conecta a los ocho avisos no es técnico sino de proceso: cada proyecto ya había corregido su falla —algunos hasta veintinueve días antes— cuando GitHub les asignó fecha de revisión el mismo 8 de setiembre. Conviene matizar lo que ese lote dice y lo que no dice: no hubo ocho fallas nuevas explotadas el mismo día, sino ocho fallas antiguas que salieron a la vez de una cola de revisión interna de GitHub. Herramientas automatizadas que solo alertan sobre avisos ya revisados —el comportamiento por defecto de Dependabot y de npm audit— no habían marcado ninguna de las ocho hasta ayer, lo que significa que equipos con escaneo automatizado de dependencias corrieron entre once y veintinueve días adicionales de exposición aparente cero, aunque el parche ya existiera. La lectura escéptica es la correcta: la etiqueta "crítico" y la fecha de publicación no equivalen a "nuevo" ni a "explotado activamente"; equivalen a "ya está en el radar de las herramientas automáticas". 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 estas librerías, pero equipos de desarrollo locales que dependen de Dependabot o npm audit para priorizar parches deberían revisar hoy si alguno de estos ocho identificadores aparece en sus repositorios, dado que la alerta automatizada llegó semanas después que el parche.
El equipo de Node.js publicó, el 8 de setiembre de 2026 a las 21:51 UTC, la versión 24.21.0 de la rama de soporte extendido (LTS) Krypton, que actualiza OpenSSL a la versión 3.5.8 y los certificados raíz al conjunto NSS 3.126, según el registro oficial de versiones del proyecto en GitHub. La misma entrega, atribuida al colaborador Antoine du Hamel, suma soporte experimental para cargar llaves privadas a través de proveedores STORE de OpenSSL, corrige la validación de configuración cuando el modo FIPS está desactivado, mejora el rendimiento de net.BlockList y del analizador de URL conforme al estándar WHATWG, y agrega pruebas de hipótesis estadísticas al módulo de histogramas de perf_hooks. La versión suma además un método MIMEType.parse() que no lanza excepciones, actualiza Undici a la 7.29.1 y Corepack a la 0.36.0, y corrige fallas puntuales en criptografía, manejo de buffers, resolución DNS y SQLite. A diferencia de los parches de seguridad que dominaron esta sección en ediciones recientes, la 24.21.0 es una entrega de mantenimiento rutinaria: no corrige ninguna vulnerabilidad con identificador CVE, según el mismo registro. La actualización de OpenSSL a la 3.5.8 sí conviene revisarla, no porque cierre una falla crítica en Node.js mismo, sino porque hereda cualquier corrección de la librería criptográfica subyacente que use TLS, certificados o cifrado a través del runtime. Krypton es, junto a las ramas 22 y 26, una de las tres líneas de Node.js que reciben actualizaciones de seguridad de forma activa al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Node.js por rama, pero es el runtime de backend más común entre equipos de desarrollo locales, desde bancos hasta startups de zonas francas tecnológicas; equipos que corren la rama Krypton en producción pueden programar la actualización a 24.21.0 dentro de su ciclo normal de mantenimiento, sin urgencia de parche de seguridad.
— La entrega, publicada anoche, actualiza OpenSSL a la versión 3.5.8 y suma carga de llaves privadas mediante proveedores STORE, dentro de la rama de soporte extendido Krypton.
cat /feed/devopscloudflareworkers.md
La versión 4.130.0 de Wrangler, publicada ayer, corrige que un comando de construcción personalizado se ejecutara dos veces y pudiera corromper compilaciones con estado; horas después, workerd extendió a 29 días su racha de lanzamientos diarios.
> Cloudflare publicó, el 8 de setiembre de 2026 a las 17:09 UTC, la versión 4.130.0 de Wrangler, la herramienta de línea de comandos para desplegar Cloudflare Workers, que suma soporte de observabilidad específica de contenedores mediante el parámetro containers[].observability en wrangler deploy, según el registro oficial de versiones del proyecto en GitHub. La misma entrega corrige que wrangler dev ejecutara dos veces el comando de construcción personalizado del usuario —al arrancar y otra vez con cada cambio de configuración—, lo que podía corromper salidas en compilaciones con estado (stateful); y optimiza el análisis carácter por carácter de wrangler d1 execute --local, que degradaba el rendimiento con archivos SQL de gran tamaño. La versión llega con las dependencias de @cloudflare/workers-types y workerd actualizadas a sus builds del 8 de setiembre.
> Unas horas después, a la 01:07 UTC del 9 de setiembre, Cloudflare publicó la versión 1.20260909.1 de workerd, el motor de ejecución de Cloudflare Workers, que actualiza el motor JavaScript V8 a la versión 15.3 y aumenta el tamaño de la pila de fibras de HTMLRewriter bajo el sanitizador de direcciones (ASan), según el mismo registro. Es la vigésimo novena entrega consecutiva de la racha diaria de lanzamientos de workerd, sostenida sin interrupciones desde el 12 de agosto. A diferencia de la entrega opaca del lunes, que esta sección documentó como la más silenciosa de la racha, la de hoy sí trae un cambio de fondo verificable: una actualización de motor no es un ajuste cosmético, dado que V8 15.3 puede alterar el comportamiento de funciones de JavaScript recién estabilizadas dentro de los Workers que corren sobre ese motor.
> 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 sus registros de compilación con estado tras actualizar Wrangler, dado que el error corregido hoy podía corromper salidas silenciosamente.
El equipo de Supabase publicó, entre el 8 y el 9 de setiembre de 2026, seis versiones beta de su interfaz de línea de comandos (CLI) rumbo a la 2.118.0: la beta.1, a las 19:54 UTC del lunes, con una reescritura mayor del runtime de "stack" y una corrección a la bandera de nivel de registro (log-level); la beta.2, una hora después, que blinda la validación del parámetro content_path contra errores de estado (stat) distintos a "archivo no encontrado", ampliando el cierre de la fuga de rutas que esta sección documentó el lunes y el martes; la beta.4, a las 22:24 UTC, que suma el comando experimental stack start; y las beta.5 a beta.9, publicadas entre la 1 y las 11:47 UTC de hoy, con actualizaciones menores de las imágenes Docker de PostgreSQL y, en la última, el comando complementario stack stop, según el registro oficial de cambios del proyecto en GitHub. El registro público no detalla en qué se diferencia el nuevo concepto de "stack" del comando supabase start existente, más allá de marcarlo como experimental en las notas de cada entrega. Es la tercera semana consecutiva que esta sección sigue el ciclo de parches del CLI de Supabase: la fuga de rutas en las plantillas de correo de autenticación, corregida el lunes; su ampliación a "cada consumidor" del parámetro content_path, corregida el martes; y hoy, un tercer ajuste sobre el mismo parámetro que ahora tolera errores de sistema de archivos que antes no contemplaba. Que el equipo siga tocando la misma validación tres días después sugiere una superficie de código más frágil de lo que el parche original dejaba ver, aunque no hay evidencia de que la falla haya sido explotada en ningún momento del ciclo, según la información disponible al cierre de esta edición. 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 siguen el ciclo beta del CLI pueden probar los comandos experimentales de stack, aunque conviene esperar a la versión estable antes de depender de ellos en un flujo de trabajo diario.
Entre las tres fallas de ejecución remota que Next.js y Astro cerraron por una librería de imágenes compartida y los ocho avisos críticos que GitHub destapó el mismo día, esta edición documenta cinco desarrollos recientes del ecosistema de programación.
Esta edición documentó cinco desarrollos del 10 de agosto al 9 de setiembre de 2026: las tres fallas críticas de ejecución remota de código que Next.js y Astro corrigieron por un problema compartido en la librería libheif de Sharp, catalogadas formalmente por GitHub el 8 de setiembre; los ocho avisos críticos en total —sumando Predis, CakePHP, GitPython, MapLibre GL y Microsoft QUIC— que GitHub revisó ese mismo día pese a que cada proyecto ya tenía parche desde semanas antes; la versión 24.21.0 de Node.js, que llevó OpenSSL 3.5.8 a la rama Krypton; la versión 4.130.0 de Wrangler y la 1.20260909.1 de workerd, que extendió a 29 días la racha diaria de Cloudflare Workers con una actualización del motor V8 a la versión 15.3; y seis versiones beta de Supabase CLI, que estrenaron comandos experimentales de "stack" mientras seguían blindando la validación de rutas que esta sección sigue desde el lunes. El hilo que conecta las dos primeras historias de hoy no es técnico sino de calendario: ocho fallas críticas, algunas corregidas hasta veintinueve días antes, aparecieron el mismo 8 de setiembre en el catálogo de GitHub simplemente porque la revisión interna del proyecto las procesó ese día. Es un recordatorio útil para cualquier equipo que confía en Dependabot o en npm audit como única red de seguridad: la ausencia de alerta no equivale a ausencia de vulnerabilidad, solo a que todavía no llegó el turno de revisión. El resto de la edición —Node.js, Cloudflare Workers y Supabase CLI— siguió el ritmo habitual de mantenimiento sin sobresaltos de seguridad propios. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición combina dos frentes: quien optimiza imágenes AVIF con Sharp en Next.js o Astro debe confirmar hoy mismo que corre una versión posterior a los parches de agosto, y quien usa Predis, CakePHP, GitPython o MapLibre GL debería revisar manualmente si alguno de los ocho identificadores de hoy aparece en sus dependencias, dado que la alerta automatizada llegó semanas tarde. El resto de la lista —Node.js, Wrangler, workerd y Supabase CLI— queda en fase de observación de rutina.