Cloudflare WAF now inspects responses: debuts to block php2shell

Cloudflare announced on 21 October two new features for its web application firewall: full transaction detection, which evaluates the entire HTTP transaction, and response rules, which act on the origin's response before it reaches the client. Site administrators behind Cloudflare, even on the free plan, will find these already active.

What's changed

Until now, Cloudflare's WAF provided protection against known attack techniques and vulnerabilities through managed rules, whilst custom rules allowed you to build policies based on IP, URL path, headers and request body. These controls operate at the request level to stop exploits or unwanted traffic before it reaches the origin.

The problem, Cloudflare explains, is that evaluating only the request forces a difficult choice between broad rules (more false positives, higher risk of blocking legitimate traffic) and narrow rules (more room for ambiguous traffic that still reaches the server). With the new feature, the WAF can correlate request and response: a path traversal attempt that returns an error tells a different story from one that returns the contents of a configuration file.

Three new fields are available for those writing custom rules:

Field	Contents
cf.waf.signature.response.confidence	Confidence level of the matching signature
cf.waf.signature.response.categories	Categories associated with the signature
cf.waf.signature.response.ref	Signature reference ID, up to 10

On the Free plan, customers can create up to 3 custom response rules, with Log and Block actions; filtering on response body is not yet available. Rules are configured under Security > Security Rules in the dashboard.

The test case: php2shell

The first managed protection based on this technique addresses the php2shell vulnerability, two critical remote code execution vulnerabilities in PHP, identified as CVE-2026-109618 and CVE-2026-109619, both with a score of 9.2 on the CVSS v4.0 scale. Official PHP patches were published around the scheduled time of 14:00 UTC on 21 October, whilst Cloudflare had already activated its default WAF rules at 03:02 UTC, before the patch.

Cloudflare CEO Matthew Prince stated that the company detected thousands of exploitation attempts in the 10 hours before public disclosure of the vulnerabilities, rising to tens of thousands within 45 minutes of disclosure, hundreds of thousands within two hours, and subsequently reaching millions. Cloudflare also observed that attackers did not simply reuse the same exploit: they modified payloads in an attempt to bypass WAF protections, apparently using feedback from blocked requests.

Those running exposed PHP servers must still update: WAF rules are defined as a stopgap, not a substitute for patching.

Cloudflare users can check rule status under Security > Security Rules; response fields are rolling out across all accounts.