Cloudflare deploys protections against php2shell vulnerability

php2shell: what was disclosed

Calif.io, Wiz, OpenAI and Quarkslab have disclosed two PHP vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named php2shell. Every web server running PHP 5.4 or later is in scope. The flaws sit in the PHP runtime itself, so when an application handles specially crafted HTTP traffic an attacker may be able to cause denial of service, achieve remote code execution, or expose data. Since PHP underpins platforms such as WordPress and Magento and is used by almost 70% of websites, the reach is broad.

The unsafe conditions arise from how PHP manages memory during request processing. Memory is allocated for a request and normally freed when that work completes; if processing halts unexpectedly — for instance on memory exhaustion — the cleanup does not happen safely. The vulnerabilities occur when PHP handles such an error and then reads data that was never fully initialized or memory that has already been released. Crafted requests trigger these paths; large requests are one way to pressure memory, but the impact goes beyond resource consumption, since manipulating the contents of that invalid memory can crash a PHP process, leak sensitive information, or run attacker-supplied code.

The two CVEs differ in when the unsafe memory access takes place:

Cloudflare's response and default coverage

Cloudflare took part in the coordinated effort alongside the PHP Foundation, OpenAI and Wiz, building and shipping WAF protections from early October 2026; these went live roughly 9 hours before public disclosure. From October 21 at 3:02 am UTC, every customer on the free or paid WAF has been protected by default.

During the period when the vulnerability leaked ahead of the official release date, Cloudflare observed attack traffic aimed at its customers and delivered several mitigations for all of them. Attackers adjusted their payloads in attempts to evade the rules; the company tracked match volumes against the rule logic to follow those mutations.

Standard request-based rules were insufficient here. Request data alone often cannot separate an exploit from legitimate traffic, whereas the origin's response supplies context showing whether an exploit worked while lowering false positives. Cloudflare therefore built full transaction detection, a WAF capability that correlates request and response signals from the same HTTP transaction and can block a matching origin response before it reaches the requester. The php2shell rules are the first managed detections shipped on top of it.

Ruleset rollout

Free customers received new rules in the Cloudflare Managed Free Ruleset (Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba) with no action needed to activate them; behavior can be overridden per the documentation.

Paid plans are covered by the Cloudflare Managed Ruleset (Ruleset ID efb7b8c949ac4650a09736fc376e9aee). Professional, Business and Enterprise customers should check that their deployment is in block mode.

The response-side rules below were deployed to the new Cloudflare Managed Response Firewall Default for all plans, Free included (rule descriptions are due to be updated):

Investigating hits and tuning scope

Blocked traffic can be examined under Security > Security Analytics > Events by filtering on the rule IDs above and reviewing the matched request, its action and its path; events show whether a managed or a custom rule fired. Where protection needs narrowing, the scope of the Managed Ruleset can be adjusted to the areas of an application that require it.

WAF coverage is only an additional layer. Because the defects live in the runtime, patching plugins or site code does nothing — administrators must update the PHP software itself, following the advisory for affected versions and remediation steps; where a hosting provider manages PHP, ask it to apply the update. Cloudflare advises patching promptly while leaving WAF protection on, and restricting and size-limiting unnecessary uploads to reduce exposure, though these measures do not substitute for the PHP fix. Analysts will keep monitoring attack activity and revise the rules as new techniques appear, with changes listed in the changelog.