Summary: On October 21, 2026, Cloudflare announced two WAF capabilities: full transaction detections, which evaluate each HTTP request alongside its response, and response rules, which can block the origin’s response before it reaches the requester. Both are generally available to all customers, including Free plans. For builders, this shifts WAF decisions from “does this request look malicious?” to “did the exploit actually work?” — a much stronger signal.
Why request inspection alone leaves a gap
Traditional WAF rules act on the request only, and that creates a false-positive dilemma. Broad signatures catch more attacks but break legitimate traffic; narrow rules stay quiet but let ambiguous requests through. The request alone often cannot tell you whether an attempt succeeded — the application might reject it, ignore it, or hand over the goods.
Cloudflare’s example: a path traversal like GET /download?file=../../config/database.ini looks suspicious, but the response determines the story. A 200 OK returning database credentials confirms exposure; an error does not. Correlating the two signals is stronger evidence than either alone.
The timing is not accidental
Cloudflare ties the release to a changing threat model. Frontier models are uncovering vulnerabilities in widely used software — the php2shell flaw is their example — and AI agents scanning for bugs can adapt payloads using feedback, chain credentials and permissions, and iterate persistently. A response that leaks “it worked” information is exactly what helps such agents go deeper.
The first managed full transaction detections target the recently disclosed php2shell vulnerability, correlating suspicious input with response content indicating a successful exploit.
Detection and enforcement are separate
The architecture mirrors Cloudflare’s earlier always-on detection framework: detections analyze traffic and attach metadata; rules decide what to do. Three new response-side fields expose signature confidence, categories, and reference IDs, usable in custom rules or Security Analytics.
Response rules then act inline. When one matches, Cloudflare replaces the origin response with a WAF block page or a custom response — a 403 instead of your leaked config file. One honest limitation: this stops data from reaching the attacker but cannot undo actions already performed at the origin, so state-changing exploits need request-side coverage too.
What you can actually build
All plans get the Cloudflare Managed Response Firewall Default ruleset (one-click, with editable scope), plus up to three custom response rules with Log and Block actions. Paying customers can combine the cf.waf.signature.response.* fields with hostname, path, IP, or headers for scoped policies.
Cloudflare’s own sample rule is instructive — it blocks only when an unauthenticated request hits /admin and the origin returns a successful HTML admin page:
http.request.uri.path starts_with "/admin"
and not http.request.headers["x-internal-user"][0] eq "true"
and http.response.code eq 200
and http.response.headers["content-type"][0] contains "text/html"Ordinary auth failures and redirects pass through. That precision — acting on outcomes rather than guesses — is the whole point.
Practical next steps
Response body rules are not yet available, and response fields are still rolling out to all accounts. If you proxy zones through Cloudflare, start by reviewing full transaction detections in Security Analytics before writing any rules — you’ll see which endpoints and signatures actually appear in your traffic. That evidence-first workflow echoes the pattern I covered in Cloudflare’s approach to verified bot accountability: observe, then enforce. Cloudflare says free plans will get managed detections for high-profile vulnerabilities while paid customers get a richer catalog, so expect coverage to expand from here.
Sources
View the original post on X