What changed
Cloudflare's October 22 changelog confirms cloudflared 2026.10.0 adds optional path normalization before matching Tunnel ingress rules that require Access JWT validation. The matcher removes dot segments ('.' and '..'), converts backslashes to forward slashes, and collapses repeated slashes, while forwarding the original unnormalized path to the origin. Normalization is disabled by default in 2026.10.0. Cloudflare plans to turn it on by default in cloudflared versions released from January 25, 2027. The upstream 2026.10.0 release notes label the change VULN-141859 ('Normalize request path when using access rules'), indicating a security-driven correction. Configurations without Access-validation rules are not affected by the announced default change.
Why it matters
Teams sometimes protect only a path such as /admin through an Access-validated ingress rule while sending other paths to the same origin without JWT validation. If an incoming path is interpreted differently by Tunnel matching and the origin server, an unexpected route may be chosen. Canonicalizing paths before Access rule selection helps align the security decision with the requested resource, but changes which ingress rule a path matches. A safe migration is to test path variants and rule ordering before the default flip, and not to assume the origin URL itself is rewritten. The precise security impact depends on a deployment's ingress configuration and origin URL handling; no confirmed exploitation or fleet-wide breakage was established.
Which request paths are treated differently
Cloudflare's updated configuration documentation shows three concrete transformations for ingress matching: /hello/../path matches as /path; /hello//path matches as /hello/path; and /hello\path matches as /hello/path. In each example, the original incoming path is still sent to the origin. These rules are relevant when Access JWT validation is configured for selected ingress paths. Matching uses the first applicable ingress rule, so ordering and fallback rules matter.
A security correction, not an origin rewrite
The cloudflared release notes for 2026.10.0 include VULN-141859: 'Normalize request path when using access rules.' Cloudflare's changelog describes the change as improving security for tunnels with rules requiring Access validation. The documentation does not say every tunnel is vulnerable or provide an exploitation count. Operators should not confuse Tunnel ingress normalization with Cloudflare's separate zone-level URL normalization feature or the October 5 Tunnel route API retirement.
How to test before January 25
For cloudflared 2026.10.0 and later, the feature is currently opt-in. Cloudflare documents the counterintuitive flag `cloudflared tunnel --disable-path-normalization=false run <TUNNEL_NAME_OR_UUID>`, or setting `TUNNEL_DISABLE_PATH_NORMALIZATION=false` for each replica and restarting. Test requests with dot segments, repeated slashes and backslashes against both Access-protected and public paths, including negative/unauthorised cases. Confirm the origin receives the expected path and that the selected ingress rule requires JWT validation where intended. Keep deployment-specific rollbacks and logs.
The future default is limited to new cloudflared releases
Cloudflare says releases starting January 25, 2027 will enable normalization by default. That is not a statement that existing pinned cloudflared binaries will silently change on that date. Teams should inventory tunnel versions, auto-update behaviour and locally managed ingress rules, then validate before adopting future builds. Configurations without rules requiring Access validation are outside the announced impact scope.