Attackers Never Sleep

Cloudflare shielded customers 9 hours before PHP disclosure

A newly disclosed pair of PHP runtime flaws, dubbed php2shell, could let attackers crash servers, leak customer data or run malicious code on any site built with PHP. Cloudflare moved first, and what its teams saw in the attack traffic changed how the company thinks about defending against them.

Oct 23, 2026 | Ethan Hula | Technology

Calif.io, Wiz, OpenAI, and Quarkslab disclosed two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as php2shell. They affect all web servers running PHP 5.4 or later and may allow denial of service, remote code execution, and data exposure when an application processes specially crafted HTTP traffic. Cloudflare deployed web application firewall (WAF) protections in early October 2026, about 9 hours before public disclosure. Starting October 21 at 3:02 am UTC, customers using the free or paid WAF were protected by default.

Cloudflare is part of a coordinated effort with the PHP Foundation, OpenAI, Wiz, and others to deploy mitigations. The vulnerability was leaked before the official release date, and Cloudflare observed attack traffic targeting its customers. Its teams watched attackers mutate the payload to try to bypass protections, tracking the volume of matches and cross-referencing them with the rule logic.

Why request rules were not enough

Protecting against php2shell required more than standard request-based rules. Request data alone does not always distinguish an exploit from legitimate traffic. The origin's response adds context, showing whether an exploit succeeded while reducing the risk of false positives.

To deliver this, Cloudflare developed full transaction detection, a new WAF capability that combines signals from the request and response within the same HTTP transaction. Response rules can block a matching origin response before it reaches the requester. The php2shell protections are the first managed detections released using this capability.

What we know about the vulnerabilities

PHP is used by almost 70% of websites. The php2shell flaws affect the PHP runtime itself and can allow attackers to execute malicious code, expose customer data, or disrupt services. Because PHP underpins platforms such as WordPress and Magento, they could affect a large number of applications.

Both flaws involve how PHP handles memory when something goes wrong while processing an HTTP request. PHP normally allocates memory for a request and releases it when the work finishes. If processing stops unexpectedly, for example because it runs out of memory, PHP fails to clean up safely. The flaws arise when PHP handles an error and then uses data that was not fully set up, or memory that has already been released.

An attacker can send specially crafted requests to trigger these conditions. Large requests put memory under pressure, but the problem goes beyond resource consumption. By manipulating the data PHP encounters in invalid memory, an attacker may crash a PHP process, expose sensitive information, or execute attacker-provided code.

The two vulnerabilities differ in when the unsafe memory access happens:

CVE-2026-109618: PHP runs out of memory and interrupts its work before some internal data is properly initialized. During cleanup, PHP may use this unfinished data as though it were valid.
CVE-2026-109619: A fatal error interrupts a request, leaving PHP holding references to memory that is released when the request ends. When the same process handles a later request, it may follow those outdated references, access invalid memory, and expose sensitive data.

These flaws sit in the PHP runtime, so updating website code or plugins alone does not fix them. Administrators must update the PHP software running their applications. If a hosting provider manages PHP, ask the provider to apply the security update. Administrators can follow the PHP advisory for affected versions and remediation steps. Keeping Cloudflare WAF protections enabled while patching is recommended. Restricting unnecessary uploads and limiting upload sizes can also reduce exposure, but these measures do not replace the PHP fix.

New rules and availability

Protections are deployed automatically on all plans with the WAF, including Free. Cloudflare customers using the Managed Ruleset are protected by default.

Free plans: New rules were released under the Cloudflare Managed Free Ruleset (Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba). Free customers need to take no action to enable the protection. The rules are:

Generic Rules – Anomalous Execution – 1: 4e315666e8e344cdb64119a3b5ccf32f
Generic Rules – Anomalous Execution – 2: 00c10e6cc4da4bd08722adeebcd95984
Generic Rules – Anomalous Execution – 3: 48ddf592361e4fdb97a8a85982dab691
Generic Rules – Anomalous Execution – 4: 3556683d512a47f2937899c524b1a4c6
Generic Rules – Anomalous Execution – 5: da07c85852e34625bb478496302ede46
Generic Rules – Anomalous Execution – 6: 19373a83abb840e18ab3ce5a7975ce1b
Generic Rules – Anomalous Execution – 7: 07f0b6ddaabf40b1b2042dade8d613fa

Paid plans (Professional, Business, Enterprise): Protection was released as part of the Cloudflare Managed Ruleset (Ruleset ID efb7b8c949ac4650a09736fc376e9aee). Review your Managed Ruleset deployment to confirm it is in block mode. The rules are:

Generic Rules – Anomalous Execution – 1: c1d409ad838f47f59446f21cc438d5dd
Generic Rules – Anomalous Execution – 2: f9a45927414245e3a64bb12d0a0c2f64
Generic Rules – Anomalous Execution – 3: 771c654ae1154d4daa72f4e1545d163c
Generic Rules – Anomalous Execution – 4: 217005865f0145f392300bac212afcc9
Generic Rules – Anomalous Execution – 5: 38efdb17ea594501bb55a1d71867b12e
Generic Rules – Anomalous Execution – 6: 4148ae686fdb4d01be673fab9d9c073d
Generic Rules – Anomalous Execution – 7: 1389aa259617437392ce149c48143645

All plans, including Free: The following rule was deployed to the new Cloudflare Managed Response Firewall Default:

Default block for High confidence Signatures: afffe22785674c80a31875c848d2242a

Cloudflare notes that rule descriptions will be updated soon. A matching full transaction rule can block the origin response before it reaches the requester. Cloudflare's full transaction detection blog post explains how it works.

Reviewing events and tuning protection

To analyze blocked requests, go to Security > Security Analytics > Events. Filter by the rule IDs above and inspect the matched request, action, and path. Events show whether the action came from a managed or custom rule. Customers who need to tailor protection can update the scope of the Managed Ruleset to the parts of an application where it is relevant. Cloudflare's security analysts will keep monitoring attack activity and update rules as new techniques and variations emerge.

Update PHP and keep the WAF on

Cloudflare recommends applying the vendor update to PHP as soon as possible, following the PHP advisory, while keeping WAF protection enabled as an additional layer of defense.

Source: blog.cloudflare.com