Cloudflare's WAF no longer just asks whether a request looks like an attack. Since October 21, 2026 it also looks at what the origin sent back, and it can block that response before it reaches the attacker. Full transaction detections and response rules are available on every plan, Free included, and the first managed rules target php2shell.
What changes
Until now, the WAF's managed rules, custom rules and rate limiting all worked on the request. Cloudflare adds two pieces:
- Full transaction detections: each request is correlated with its response to look for evidence that an exploit actually worked.
- Response rules: when a rule matches, Cloudflare swaps the origin response for its block page (HTTP 403) or a custom response.
Cloudflare's own example makes the point. A GET /download?file=../../config/database.ini is an obvious path traversal, but the request alone does not tell you whether the app handed over the file. If the origin answers 200 OK with something that looks like an .ini file with a username and password, the pair is far stronger evidence than either signal on its own.
Why it matters
Request inspection forces a trade-off between broad signatures, which throw false positives and break legitimate traffic, and strict ones, which let ambiguous traffic through. Looking at the outcome lets you be aggressive only when there is evidence of impact. Cloudflare also points to vulnerability-hunting agents: they keep trying, adapt payloads based on what the app returns and chain flaws together, so the response is exactly what lets them go further.
For an SRE team the practical value is different: a rule that only fires once the origin has already failed is a safety net for the gap between a CVE going public and the patch reaching production, as happened with php2shell.
What each plan gets
| All plans (Free included) | Paid plans | |
|---|---|---|
| Cloudflare Managed Response Firewall Default managed ruleset | Yes, focused on high-profile vulnerabilities | Yes, with a broader catalog |
| Custom response rules | Up to 3, with Log and Block actions | Up to 3, with the fields of your plan |
cf.waf.signature.response.* fields | No | Yes (rolling out) |
| Rules on the response body | Not available yet | Not available yet |
The new fields are cf.waf.signature.response.confidence, cf.waf.signature.response.categories and cf.waf.signature.response.ref (up to ten signature IDs), mirroring the request-side Attack Signature Detection fields. If your account does not have them yet, Cloudflare asks you to reach out to your account team.
How to turn it on
The controls live at the bottom of Security > Security Rules in the dashboard. The managed ruleset runs on every request by default; you can narrow its scope to a path or exclude parts of the app if it misfires.
A handy custom rule protects an admin panel that should only ever be reached through an authentication gateway. This expression, adapted from Cloudflare's example, blocks only when a request without the internal header gets a 200 HTML page back from the origin:
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"It leaves login redirects and auth failures alone and only kicks in when the origin has actually served the panel. Events show up in Security Events under the Managed Rules or Custom Rules service, and you can filter them by rule ID.
The caveat that matters
Blocking the response does not undo what already happened at the origin. If the exploit was a write, a remote code execution or a delete, the rule stops the attacker from seeing the result, but the damage is done. This is a layer for containing data leaks and confirming exploitation, not a replacement for patching. And since rules on the response body are not available yet, spotting sensitive data in content depends on Cloudflare's managed signatures.