On November 12, 2026, Cloudflare released cloudflared 2026.11.0, the agent that keeps a Cloudflare Tunnel open between your server and Cloudflare's network. It extends the URL normalization that shipped in 2026.10.0 on October 22, and it moves the date when that behavior becomes the default: new cloudflared releases published from February 8, 2027 will ship with normalization on. The earlier announcement said January 25.
What normalization does to routing
The Tunnel decides which service gets each request by comparing the hostname and, optionally, the path against a list of ingress rules. Rules are read top to bottom and the first match wins. The path field takes a regular expression.
With normalization on, cloudflared cleans up the path before that comparison. According to the docs, it resolves . and .. segments, turns backslashes into forward slashes and merges repeated slashes. Version 2026.11.0 also strips semicolon-delimited parameters, as in /admin;x=1/. The path sent to the application stays the original: /hello/../path matches the /path rule, but the origin receives /hello/../path.
Cloudflare frames the change as a security improvement for rules that require Cloudflare Access validation, the access parameter with required: true. In that mode, cloudflared checks the Access JWT before forwarding traffic to the origin.
Who needs to review their configuration
The docs say configurations without Access validation rules are unaffected. The group that needs to look is narrower: teams that expose internal applications through the Tunnel, protect some of them with access.required and use path rules to separate protected from unprotected traffic. An admin panel served on the same hostname as the public site, with a rule just for /admin, is the typical shape.
My reading of the reason, which Cloudflare does not spell out: when the protected rule depends on a regular expression over the path, a URL written differently (with .., a double slash or ;) may not match it and fall through to a later rule without validation, while the application server reads the same path as the protected area. Normalization makes cloudflared compare the form the origin is likely to understand.
That has two practical effects. While normalization is off, such a configuration depends on the regex covering every way of writing the path. Once it is on, requests that land on one rule today may land on another, and a route that works today may change destination.
What to do before February 8
For teams in that group, the work fits in one maintenance task:
- upgrade
cloudflaredto 2026.11.0 or later on every tunnel replica; - turn normalization on in a test environment with
cloudflared tunnel --disable-path-normalization=false run <tunnel>or withTUNNEL_DISABLE_PATH_NORMALIZATION=false, restarting each replica; - check with
cloudflared tunnel ingress rule <URL>which rule each important path hits, including variants with..,//and;; - then turn it on in production, without waiting for the default to change.
There is a reason not to let the date decide. It applies to new releases, not to the tunnel already running. Teams that pin cloudflared in an image or package stay without normalization until they upgrade, and teams that upgrade automatically after February 8 get the routing change without having tested it.
If you do not use Access validation on the Tunnel, nothing changes for now.
What Cloudflare has not explained yet
Both notices talk about "improving security" without describing a flaw, a CVE or a case of unauthorized access. They also do not say whether normalization will stay limited to Access rules once it becomes the default, or whether the February 8 date could move again, as it already did once. Until that is clarified, the safe course is to treat path rules in front of protected applications as something that needs an explicit test, with or without the flag.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
