Cloudflare WAF Now Checks What Applications Return

Summary

Cloudflare’s October 21 release adds a security decision after an application responds. Full transaction detection correlates the incoming request with the origin’s reply; response rules can stop that reply reaching the requester. That is a useful additional boundary, but it cannot reverse actions already performed at the origin.

Key Updates

Response evidence becomes actionable. The capability is generally available for traffic proxied through Cloudflare, including Free plans. Customers can create up to three custom response rules with Log or Block actions. Custom rules cannot yet match response bodies. Detection-result fields for custom rules require a paid plan and are still rolling out. These limits differ from Cloudflare’s managed detections, whose first application is php2shell. Cloudflare’s release describes the distinction.

The PHP incident supplies the immediate use case. Cloudflare says its PHP protections reached free and paid WAF customers before public disclosure on October 21. The managed response firewall was deployed automatically across plans; paid customers should confirm that their Managed Ruleset runs in block mode. Its incident report also stresses that updating website code or plugins alone does not fix flaws in the PHP runtime.

The maintainer advisory defines the repair. PHP identifies CVE-2026-109618 and CVE-2026-109619 as critical flaws that can allow unauthenticated remote code execution. Its October 21 advisory covers PHP installations serving web requests, with the highest stated risk for Apache mod_php. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Operators using distribution or long-term-support packages should verify the vendor’s patched build. Older upstream branches require a supported upgrade or a verified backport; the advisory also provides limited source backports. PHP’s maintainers say temporary mitigations reduce particular exposures but do not make an installation safe. PHP advisory.

Why It Matters

Our earlier dependency-remediation coverage separated containment from repair. This release adds a more specific operational question: at what point does a control intervene?

The client-visible result and the origin’s execution history are different evidence. An operator who sees a block page still needs to understand what happened upstream. That distinction should shape incident triage and the evidence required to close a remediation task. Neither a clean dashboard nor a successful update establishes absence of earlier compromise.

Builder Takeaway

Review one PHP-backed route from ingress to response. Record the checks that act before the origin and those that act afterward. In a safe test environment, compare origin logs with the client-visible outcome; include normal application traffic to check for unintended blocking.

Keep two completion records: the firewall policy and observed behavior, and the deployed PHP package or image verified against its vendor’s fix. Assign an owner to each. If a hosting provider manages the runtime, request evidence of the deployed update. These are proposed verification steps, not tests performed for this article.