Security operations · November 12, 2026
Cloudflare’s November 12 Tunnel update adds semicolon-delimited path-parameter handling in cloudflared 2026.11.0. It also moves the normalization default change for new releases to February 8, 2027, explicitly replacing January 25. The setting remains off by default today. Configurations without ingress rules requiring Access validation are unaffected.
For operators, the useful next step is a routing test with a clear expected result for every protected path. Treat the revised date as a planning boundary, not evidence that an existing tunnel has already changed behavior.
Separate rule matching from the origin request
The ingress documentation explains that normalization removes dot segments, converts backslashes and merges repeated slashes; 2026.11.0 also removes semicolon-delimited parameters for matching. The original request path still reaches the origin. Rules are evaluated in order, with the first match selected.
This distinction matters when the tunnel and application interpret the same path differently. Build a small inventory of intended destinations and protection requirements before changing a flag. Include application-owned paths containing semicolons, ordinary paths, nested routes and unmatched requests. Keep the expected origin and expected authentication result in separate columns in your test record.
Enable deliberately in an authorized test environment
The run-parameter reference uses an inverse flag: --disable-path-normalization=false enables normalization. The equivalent environment variable is TUNNEL_DISABLE_PATH_NORMALIZATION=false. Cloudflare’s announcement says to set it on each replica and restart. Use 2026.11.0 or later when testing the expanded behavior.
Record each replica’s actual version and effective setting. A successful request through one instance is not sufficient evidence for the fleet. Test only systems you administer or have permission to assess, with synthetic requests and non-sensitive test accounts. Keep the experiment separate from production changes and use your normal change-approval process.
Check authorization, not just a successful response
When enabled, Cloudflare’s Access origin setting makes cloudflared validate an Access JWT before forwarding traffic. In your acceptance checks, compare an authorized user with an unauthenticated request and an identity that should not have access. Confirm the selected origin, application behavior and denial outcome, rather than accepting an HTTP success code as proof of correct protection.
Before rollout, assign a change owner and define stop conditions: an unexpected destination, a previously rejected request being accepted, or a legitimate workflow failing. Keep a known working configuration in your existing change-management system and agree how to restore service without silently removing Access protection. Recheck the vendor’s current schedule when scheduling the production change.
Which date should the change ticket use?
The October 22 post still displays January 25, 2027. The November 12 update explicitly supersedes it with February 8. Attach the newer notice to your ticket so another reviewer does not mistake the older page for the current deadline.
Scope: This is a public-source briefing and a suggested validation plan. SysSeder has not tested a deployment or established an exploit or CVE. The announced default applies to new releases from the stated date; it does not say every running installation switches automatically that day.