Cloudflare’s PHP2Shell rules still leave PHP updates to the host

A web application firewall, usually shortened to WAF, filters web traffic. The origin is the server that actually runs your website’s PHP. Cloudflare’s PHP2Shell response describes protection at the firewall and tells customers to update PHP while keeping that protection enabled.

A response block happens after the server has replied

Some of Cloudflare’s new detection checks both sides of a web exchange: the incoming request and the origin’s response. If a response matches a blocking rule, Cloudflare can replace it before it reaches the requester. That can prevent a response containing sensitive information from being delivered.

However, the origin has already processed the request. Cloudflare’s description of full transaction detection says response blocking cannot reverse actions already performed there. When reviewing an event, identify whether Cloudflare stopped the request before it reached PHP or blocked the response afterward. A response block is a reason to examine origin activity.

Check the deployment in your account

The WAF changelog records seven additions to the Managed Ruleset and seven to the Free Ruleset on October 21, all with Block actions. October 22 entries changed rule names and descriptions to identify the CVEs without changing detection or actions.

Cloudflare says its Managed Response Firewall Default was deployed automatically for customers on all plans. Account settings still matter: a rule can be disabled, given another action, restricted to certain paths or bypassed by an exception. The managed-rules documentation explains those controls.

1. Open the affected website’s Security settings and confirm its applicable managed rules are enabled.
2. Inspect Security Rules for the response firewall, its scope and any exceptions.
3. Review matched events in Security Analytics. Record the rule, action, requested path and time, then compare relevant events with your server logs.

These checks establish how your account is configured. They do not establish which PHP build your host is running or whether an earlier request succeeded.

Check hostnames and direct access

Cloudflare’s proxy-status documentation distinguishes proxied records from DNS-only records. Proxied web traffic passes through Cloudflare. DNS-only records send clients to the origin, where Cloudflare’s web protection does not inspect the request.

Check the hostnames used for the public site, administration pages and other PHP applications. Your administrator should also review direct access to the origin using Cloudflare’s origin-protection guidance. Changing one hostname’s proxy setting does not cover every route to a server.

Confirm the host’s package and restart

Ask the host which supplier provides PHP, which complete package revision contains the fixes for CVE-2026-109618 and CVE-2026-109619, and which build is now serving your domain. A vendor may backport security changes into an older branch, so a short PHP version label can be misleading. Our backport guide explains how to read those revisions.

Keep the package update and restart confirmation with your Cloudflare checks. On Ubuntu with Apache’s PHP module, Canonical says Apache must restart after the update. Other PHP setups need their own service-specific checks. Also review the separate October 23 session-upload-progress advisory with the person who manages PHP.

Sources

This article uses Cloudflare’s response report, full transaction explanation, changelog and configuration documentation linked above. They describe Cloudflare’s published behavior as checked on October 23; we have not inspected an individual reader’s account.

Next: use the running-PHP verification guide to finish the origin update check with your host or administrator.