Cloudflare WAF Moves New HTTP/2 and XSS Detections from Log to Block

Cloudflare changed the enforcement state of four managed WAF detections on August 25, 2026. One HTTP/2 request-smuggling body anomaly detection and three JavaScript event-handler coercion detections moved from Log to Block. The same release merged a beta script-tag detection into its original rule and added a generic remote-code-execution detection in blocking mode.

The operational lesson for authorized data collection, API monitoring, ad verification, and application QA is straightforward: a request that worked before the rule promotion may now receive a block response even when the proxy route, exit country, and credentials are unchanged. That does not prove the proxy failed, and it does not justify trying to disguise or mutate traffic until it passes.

What changed

The official release lists four detections promoted from observation to enforcement:

• an HTTP/2 request-smuggling request-body anomaly;
• JavaScript event-handler coercion in request headers;
• the same coercion pattern in the request body;
• the same pattern in the request URI.

Moving a rule from Log to Block changes the outcome at the edge. During the logging phase, the request could continue while the event was recorded. In blocking mode, a matching request can be stopped before it reaches the origin application.

Cloudflare also merged its beta script-tag rule into the established XSS and HTML-injection rule, and introduced a generic remote-code-execution detection in blocking mode. These changes affect detection and enforcement at the application-security layer; they do not describe a change to residential proxy routing or IP allocation.

Why a new 403 is not automatically a proxy problem

A proxy problem and a WAF decision can produce similar client symptoms: a non-success status, an HTML block page, or a connection that never reaches the expected API handler. The evidence needed to separate them is different.

If the proxy cannot connect, the client may see a tunnel error, DNS failure, TLS failure, or timeout before an HTTP response exists. If the WAF blocks a structurally valid request, the client normally receives an HTTP response from the protected edge. The status alone is insufficient; teams should compare the response class, timing, edge request identifier when available, proxy gateway observation, and origin access logs.

Use one harmless correlation ID across the client, proxy, edge, and application logs. Never place secrets or personal data in that identifier.

A safe investigation sequence

When a previously successful authorized workflow begins receiving blocks, use a controlled comparison:

1. Freeze the application version, request payload, proxy session, target route, and concurrency.
2. Reproduce once at concurrency one and retain sanitized status, response headers, timing, and a payload hash.
3. Confirm whether the request reached the intended proxy gateway.
4. Confirm whether the origin application received the request.
5. Ask the site or API owner to inspect the matching WAF event and rule identifier.
6. Compare the request with the published API contract or browser flow you are authorized to automate.
7. Correct malformed or ambiguous request construction at the source.
8. Re-test the corrected request with the same route before changing exits.

Do not rotate through many IPs, randomize headers, replay credentials across exits, or increase concurrency. Those actions destroy the controlled comparison and can turn a single request defect into abusive traffic.

Check HTTP/2 framing and body consistency

The new HTTP/2 request-body anomaly enforcement deserves special attention in custom clients, gateways, and protocol-conversion stacks.

Validate that the client and every intermediary agree on the request method, body length, transfer semantics, content type, and end-of-stream boundary. Remove duplicate or contradictory length indicators. Do not reuse an HTTP/1-specific workaround in an HTTP/2 path without verifying how the library translates it.

Teams using an HTTP proxy should test whether the client sends a direct HTTP/2 connection after a tunnel is established or uses a different protocol toward the gateway. Record the negotiated application protocol on each controlled hop. For SOCKS routes, separately record where DNS is resolved and which address family reaches the destination.

The goal is not to discover a pattern that slips past inspection. The goal is to prove that each layer emits one unambiguous request that matches the application contract.

Check URI, headers, and bodies for unintended script-like values

The three XSS-related promotions cover the URI, headers, and body. Legitimate automation can accidentally create suspicious values when it:

• concatenates unvalidated user input into a URL;
• serializes HTML fragments where plain data is expected;
• places event-handler-like field names in a custom header;
• double-encodes or inconsistently decodes parameters;
• submits a browser DOM fragment instead of a documented API field;
• mixes content types and encodings.

Fix the data model and encoding boundary. Validate field types before serialization, use the declared content type, and encode once at the correct layer. If a legitimate business field still matches a managed rule, the application owner—not the data collector—should review the event and decide whether a narrowly scoped exception is appropriate.

Build a regression record before resuming scale

After correction, preserve a small regression record:

Only ramp concurrency after the single-request fixture passes repeatedly. Keep the prior blocked fixture for a negative test if the application owner approves it; it should continue to be rejected.

What buyers of proxy services should measure

Proxy evaluation should separate transport quality from application acceptance. Measure connection success, TLS completion, DNS behavior, address-family behavior, latency, exit stability, and target response as different fields. A provider cannot guarantee that a malformed or policy-violating application request will be accepted by a third-party WAF.

For an auditable workflow, combine this investigation with 98IP's internal guides on proxy route leak detection, HTTPS proxy TLS troubleshooting, and WebSocket proxy lifecycle testing.

Compliance note

Run these tests only against systems you own or are authorized to assess. Respect access controls, published API terms, robots directives where applicable, privacy obligations, and rate limits. Do not use proxies to bypass a WAF, conceal prohibited access, or evade enforcement. If a legitimate request is blocked, coordinate with the application owner and correct or allowlist the documented workflow through their approved process.

Source note: Cloudflare, “WAF Release - 2026-08-25,” published August 25, 2026. The public article records the institution, title, and date in plain text under 98IP's zero-external-link policy.