Key details

  1. Cloudflare changelog published October 22, 2026; cloudflared 2026.10.0 supports path normalization.
  2. New cloudflared releases from January 25, 2027 are planned to enable it by default.
  3. Normalization applies before Access-protected ingress rule matching; origin receives the original path.
  4. Dot segments, backslashes and repeated slashes are normalized for rule selection.
  5. Cloudflare's 2026.10.0 release notes label the security work VULN-141859.
  6. Opt in with --disable-path-normalization=false or TUNNEL_DISABLE_PATH_NORMALIZATION=false; restart replicas.
  7. No confirmed real-world exploitation or universal compatibility impact was established.

What builders should take away

  1. Inventory cloudflared versions and path-specific ingress rules that validate Cloudflare Access JWTs.
  2. Test normalized and unnormalized path variants against protected and fallback ingress rules; verify denial as well as allowed access.
  3. Enable normalization in a controlled staging or canary tunnel before new releases flip the default.
  4. Do not assume origin paths change: inspect what the origin actually receives.
  5. If a tunnel has no Access-validation ingress rules, Cloudflare says this default change does not affect it.
  6. Separate this from Cloudflare's October 5 Tunnel route API migration; they are different changes.

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.

What to watch next

  • Cloudflare confirmation of the January 25, 2027 default change and any altered rollout date.
  • Additional cloudflared release notes or advisories clarifying VULN-141859 and affected configurations.
  • Reports of legitimate route-matching regressions or bypass attempts after opt-in.

Still unclear

  • No public quantified exploitation or affected-installation count was established.
  • Whether Cloudflare adjusts the rollout date or adds migration tooling remains unknown.
  • The precise security impact depends on each deployment's ingress rules and origin path interpretation.

Sources

Direct reading behind this dossier.

4 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment