Cloudflare anuncia reglas por Brotli: revisa los bloqueos heredados
Índice de contenidos
Claves de la noticia
- Cloudflare anuncia dos reglas de emergencia vinculadas a Brotli y al optimizador de imágenes de Next.js.
- La acción predeterminada es registrar coincidencias; una configuración general previa puede convertirlas en bloqueos.
- Revisar la acción efectiva y actualizar el software son tareas distintas: el cortafuegos no sustituye al parche.
Cloudflare ha publicado este 25 de octubre una actualización de emergencia de su cortafuegos web relacionada con CVE-2026-111497. Para quienes administran aplicaciones, el detalle decisivo está en la configuración heredada: una regla anunciada en modo de observación puede terminar interrumpiendo peticiones si el conjunto tiene una anulación que impone bloquear.
Dos señales amplias para empezar a observar
El aviso oficial de Cloudflare presenta dos detecciones nuevas con acción Log. Una identifica cuerpos de petición declarados como Brotli mediante Content-Encoding: br; la otra señala el acceso a /_next/image. El proveedor advierte de que ambas pueden coincidir con tráfico legítimo. Por tanto, una coincidencia no demuestra por sí sola un intento de explotación.
La diferencia entre observar y rechazar afecta directamente a la disponibilidad. Un comercio que utiliza el optimizador de Next.js podría perder imágenes si transforma indiscriminadamente sus coincidencias en bloqueos. En el otro caso, puede denegar clientes que envían cuerpos comprimidos válidos. Son consecuencias que se desprenden del alcance declarado de las detecciones, no incidentes medidos en tiendas españolas.
También conviene distinguir dos cabeceras parecidas: declarar cómo viene comprimido un cuerpo enviado al servidor no equivale a comunicar qué compresión acepta el cliente para la respuesta. Cambiar la compresión de salida sería actuar sobre otro tramo de la comunicación. Esa distinción evita convertir una medida de seguridad del servidor en un ajuste de rendimiento sin relación con la entrada inspeccionada.
La configuración antigua también gobierna reglas nuevas
La documentación de anulaciones del motor de reglas explica la jerarquía: una modificación específica de regla tiene prioridad sobre una de etiqueta, y esta sobre la del conjunto completo. Las anulaciones generales y por etiqueta alcanzan además a reglas futuras. Una decisión tomada meses atrás puede, por tanto, cambiar el efecto de una incorporación que el administrador todavía no ha revisado.
Al cruzar esa jerarquía con el anuncio de hoy aparece una comprobación concreta: la acción publicada no basta para conocer la acción que ejecutará una instalación. Hay que revisar también lo que hereda. El problema no exige que Cloudflare cambie silenciosamente el valor anunciado; puede surgir al aplicar una política general que ya existía.
| Configuración | Resultado que debe revisarse |
|---|---|
| Sin anulación aplicable | Se conserva la acción predeterminada. |
| Bloqueo para todo el conjunto | Puede alcanzar también a las reglas recién añadidas. |
| Anulación específica de una regla | Prevalece sobre las modificaciones más generales. |
La tabla resume la prioridad documentada, no una prueba sobre una cuenta de cliente. Su conclusión práctica es que comprobar únicamente el interruptor de la nueva detección deja incompleta la revisión. La acción efectiva depende del lugar donde se fijó la política y de las excepciones aplicables.
El fallo de Brotli sigue dentro del software
El antecedente técnico es el boletín de seguridad de Node.js del 21 de octubre. Describe un error del decodificador Brotli: una entrada inválida se interpreta como necesidad temporal de más datos y continúa escribiendo sobre un búfer interno de ocho bytes. La corrupción de memoria puede provocar una caída, revelar memoria o permitir ejecución de código. El proyecto clasifica el problema como de gravedad alta y sitúa entre las ramas afectadas las versiones 22, 24 y 26.
Ese antecedente ya formaba parte de los parches de octubre para las tres ramas de Node.js. La novedad de hoy es la política del cortafuegos y su posible interacción con configuraciones anteriores. No constituye el descubrimiento de otra vulnerabilidad ni demuestra que todas las aplicaciones Next.js sean explotables.
La separación de responsabilidades importa: filtrar una entrada concreta puede reducir exposición en un recorrido, mientras actualizar elimina el componente vulnerable en el entorno corregido. Una regla aplicada en la entrada pública no permite deducir el estado de todas las operaciones de descompresión de una aplicación. Tampoco un registro de coincidencias equivale a impedir que la petición llegue al programa.
Revisar disponibilidad sin desactivar la defensa entera
Para investigar efectos indeseados, Cloudflare documenta el uso de Security Events y la resolución de falsos positivos. La revisión debe relacionar la regla que coincide con la petición legítima afectada. Desactivar todo el conjunto para recuperar una imagen elimina un ámbito de protección mucho mayor que el problema observado. Las excepciones y los ajustes específicos permiten acotar el cambio, aunque su conveniencia depende de cada aplicación.
El mismo documento recuerda que el cortafuegos solo actúa sobre tráfico que pasa por Cloudflare y que es necesario desplegar el conjunto correspondiente. Tener el dominio en el proveedor no demuestra que todas sus peticiones recorran esas comprobaciones. Antes de interpretar la ausencia de eventos como ausencia de riesgo, hay que verificar el recorrido real hasta el origen.
Para una web española, la decisión útil combina continuidad y corrección: comprobar imágenes y clientes legítimos, revisar la política heredada y acreditar la versión del software que sirve tráfico. Un bloqueo general puede romper una función válida; un registro correcto puede dejarla expuesta. El anuncio no permite elegir por defecto entre ambos resultados sin revisar la aplicación concreta.




