Cloudflare WAF blocks new GitLab path traversal and tightens request‑smuggling rules

On 30 September 2026 Cloudflare updated its Managed WAF ruleset, adding a detection for a GitLab path‑traversal flaw (CVE‑2026‑85706) and shifting several existing rules from logging to active blocking. The change also merges two beta rules into their stable counterparts and disables a duplicate command‑injection rule.

New detections and rule actions

• GitLab path traversal – rule c825487afc274e34966052bb87ae8cfc now blocks traffic that matches the CVE‑2026‑85706 pattern; previously it only logged.
• Directory traversal – rule f2445b9131214302a11477a2cb14ded8 upgraded from Log to Block, providing active protection against generic traversal attempts.
• HTTP request smuggling – request body anomaly (beta) – rule 5c1ba1fdb0a742d4beaaefd00364bd7e now blocks and is merged into the stable rule a80f214f0947435dabb2ba2d1489d892.
• Generic request‑routing cache inconsistency – new rule 86b0681d72234ef7bd6f67c7549f7356 introduced with a Block action.
• Command injection – generic 8 – body (beta) – rule 09055ff9f80046419a3c0be5d498a69a remains Disabled and is merged into the original rule 5b3ce84c099040c6a25cee2d413592e2.

Why the shift matters for engineers

Changing a rule from Log to Block alters the traffic flow: requests that would have been allowed (and merely recorded) are now dropped at the edge. AI engineers exposing model endpoints through Cloudflare must verify that legitimate inference calls are not inadvertently blocked. Cloud and platform engineers need to update their observability pipelines to capture the new block events, as they will appear in WAF logs rather than application logs. DevOps and SRE teams should anticipate a potential rise in alert volume and be prepared to adjust rate‑limiting or retry logic in automated pipelines. Security engineers gain immediate mitigation for the disclosed GitLab vulnerability and for generic request‑smuggling techniques, reducing reliance on downstream detection.

Operational considerations

All teams should pull the latest rule identifiers from the Cloudflare dashboard and map them to existing monitoring dashboards. Because some rules were merged, alert signatures that referenced the original beta IDs may need to be updated to the stable IDs. The new Block actions can surface false positives; a staged rollout or testing window is advisable before enforcing globally. Performance impact is expected to be minimal, but the increase in rule evaluation count should be verified against latency budgets. Finally, the disabled command‑injection rule indicates that the detection is now covered elsewhere, so duplicate custom rules should be reviewed to avoid redundancy.

Related CloudNinjas coverage: security.

What This Means For Practitioners

• Audit the Cloudflare Managed Ruleset for the listed rule IDs and confirm that the new Block actions align with your risk tolerance.
• Run targeted tests against endpoints that handle file paths, GitLab integrations, or HTTP/2 traffic to ensure legitimate requests are not blocked.
• Update alerting thresholds to account for the expected increase in blocked‑request events.
• Document the rule‑ID changes in runbooks so on‑call engineers can quickly differentiate between merged and deprecated rules.
• Consider adding custom allow‑list rules if critical traffic is impacted by the new blocks.