El 12 de noviembre de 2026, Cloudflare publicó cloudflared 2026.11.0, el agente que mantiene abierto el Cloudflare Tunnel entre el servidor y la red de Cloudflare. La versión amplía la normalización de URL que llegó en la 2026.10.0, el 22 de octubre, y cambia la fecha en que ese comportamiento pasa a ser el predeterminado: las versiones nuevas de cloudflared publicadas a partir del 8 de febrero de 2027 vendrán con la normalización activada. El anuncio anterior hablaba del 25 de enero.
Qué hace la normalización en el enrutamiento
El Tunnel decide a qué servicio enviar cada solicitud comparando el hostname y, de forma opcional, la ruta con una lista de reglas de entrada (ingress). Las reglas se leen de arriba abajo y gana la primera que coincide. El campo path acepta una expresión regular.
Con la normalización activa, cloudflared limpia la ruta antes de esa comparación. Según la documentación, resuelve los segmentos . y .., convierte barras invertidas en barras normales y une barras repetidas. La versión 2026.11.0 añade la eliminación de parámetros separados por punto y coma, como en /admin;x=1/. La ruta enviada a la aplicación sigue siendo la original: /hello/../path coincide con la regla de /path, pero el origen recibe /hello/../path.
Cloudflare presenta el cambio como un refuerzo de seguridad para las reglas que exigen validación de Cloudflare Access, el parámetro access con required: true. En ese modo, cloudflared verifica el token JWT de Access antes de reenviar el tráfico al origen.
Quién tiene que revisar la configuración
La documentación dice que las configuraciones sin reglas de validación de Access no se ven afectadas. El grupo que debe revisar es más reducido: equipos que exponen aplicaciones internas a través del Tunnel, protegen parte de ellas con access.required y usan reglas con path para separar lo protegido de lo que no lo está. Un panel de administración publicado en el mismo hostname del sitio, con una regla solo para /admin, es el caso típico.
Mi lectura del motivo, que Cloudflare no detalla: cuando la regla protegida depende de una expresión regular sobre la ruta, una URL escrita de otra forma (con .., barra doble o ;) puede no coincidir con esa regla y caer en una regla posterior sin validación, mientras el servidor de aplicación interpreta la misma ruta como el área protegida. La normalización hace que cloudflared compare la forma que el origen probablemente va a entender.
Eso tiene dos efectos prácticos. Mientras la normalización esté desactivada, una configuración así depende de que la expresión regular cubra todas las formas de escribir la ruta. Cuando se active, solicitudes que hoy caen en una regla pueden pasar a caer en otra, y una ruta que funciona hoy puede cambiar de destino.
Qué hacer antes del 8 de febrero
Para quien está en ese grupo, el trabajo cabe en una tarea de mantenimiento:
- actualizar
cloudflareda la 2026.11.0 o posterior en todas las réplicas del túnel; - activar la normalización en un entorno de prueba con
cloudflared tunnel --disable-path-normalization=false run <túnel>o con la variableTUNNEL_DISABLE_PATH_NORMALIZATION=false, reiniciando cada réplica; - comprobar con
cloudflared tunnel ingress rule <URL>qué regla alcanza cada ruta importante, incluidas las variantes con..,//y;; - recién entonces activarla en producción, sin esperar el cambio de valor predeterminado.
Hay una razón para no dejar que la fecha decida. Vale para versiones nuevas, no para el túnel que ya está en marcha. Quien fija la versión de cloudflared en una imagen o un paquete sigue sin normalización hasta actualizar, y quien actualiza de forma automática después del 8 de febrero recibe el cambio de enrutamiento sin haberlo probado.
Para quien no usa validación de Access en el Tunnel, por ahora no cambia nada.
Lo que Cloudflare todavía no explicó
Los dos avisos hablan de "mejorar la seguridad" sin describir una falla, un CVE ni un caso de acceso indebido. Tampoco dicen si la normalización seguirá limitada a las reglas con Access cuando pase a ser el valor predeterminado, ni si la fecha del 8 de febrero puede volver a cambiar, como ya cambió una vez. Mientras eso no se aclare, lo prudente es tratar las reglas de ruta delante de aplicaciones protegidas como algo que necesita una prueba explícita, con o sin la flag.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
