php2shell: Patching the PHP Runtime While WAF Rules Stay On

Cloudflare's advisory, Cloudflare deploys protections against php2shell vulnerability, says that Calif.io, Wiz, OpenAI and Quarkslab disclosed the two vulnerabilities. It describes the flaws as sitting in the PHP runtime itself. The advisory states that updating website code or plugins alone does not fix them, and it recommends keeping Cloudflare WAF protections enabled while the PHP update is applied.

This article covers what the Cloudflare sources state about the vulnerabilities, which versions and rulesets they name, the protection steps they recommend, and how to check whether a deployment is in scope. Where the sources give no value, such as a fixed PHP release, this article says so rather than filling the gap.

What the two vulnerabilities do #

Both flaws concern how PHP handles memory when processing goes wrong during an HTTP request. The advisory describes the normal behavior first: PHP allocates memory to hold the data it needs for a request, then releases that memory when the work finishes. If processing stops unexpectedly, the advisory says PHP does not always clean up that memory safely. Running out of memory is one example of an unexpected stop it gives.

The advisory lists the two CVEs separately because the unsafe memory access happens at different points:

• CVE-2026-109618: PHP runs out of memory and interrupts its work before some internal data has been properly initialized. During cleanup of that request, 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 PHP process handles a later request, it may follow those outdated references and access memory that is no longer valid, which can expose sensitive data.

The advisory states that an attacker can trigger these conditions by sending specially crafted HTTP requests. Large requests are one way to put memory under pressure, but the advisory says the problem goes beyond resource consumption. According to the advisory, manipulating the data PHP encounters in invalid memory may allow an attacker to crash a PHP process, expose sensitive information, or execute code the attacker provides.

The advisory also states that PHP is used by almost 70% of websites, and that PHP underpins widely used platforms such as WordPress and Magento. The sources do not say how many deployments are exploitable, because the advisory ties the impact to the memory conditions described above.

Affected and fixed versions #

The table separates what each source states. The Cloudflare advisory gives one version boundary, PHP 5.4 or later, and it does not name a fixed PHP release. For fixed versions and remediation instructions, the advisory points readers to the PHP advisory. The WAF rows describe protections rather than affected software, so they show a status instead of a version.

Protection steps #

The Cloudflare advisory lists several actions. The sources present them as recommendations and do not rank them, so the list below follows the order in which the advisory presents them.

1. Update the PHP runtime on every server that runs your applications. The advisory states that the flaws are in the PHP runtime, so a website code or plugin update alone does not fix them.
2. If a hosting provider manages PHP for you, ask the provider to apply the security update.
3. Keep Cloudflare WAF protections enabled while you patch. The advisory describes these protections as defense-in-depth mitigation, in addition to the vendor update.
4. On Professional, Business, or Enterprise plans, review your Managed Ruleset deployment and confirm it is in block mode.
5. Restrict unnecessary uploads and limit upload sizes. The advisory says these measures can reduce exposure but do not replace the PHP fix.
6. Review blocked requests in Security Analytics. If you need to tailor the protection, narrow the scope of the Managed Ruleset to the parts of your application where it is relevant.

How to check whether you are affected #

The Cloudflare advisory identifies the affected population by runtime rather than by application. An application can be current while the PHP runtime beneath it is still in the affected range. The first check is therefore the PHP version on each server or container that serves your application. The advisory states the affected range as PHP 5.4 or later. Because it does not name a fixed release, compare your installed version against the PHP advisory it references. The sources do not treat the absence of a Cloudflare warning as confirmation that a server has been patched, and this article does not either.

Check every place PHP runs, including application servers, hosted environments, and container images. Where a hosting provider manages PHP, the advisory's guidance is to ask the provider to apply the update. Where PHP runs inside a container image, the runtime inside that image is the component that needs updating.

For WAF protection, the advisory says Free customers do not have to take action to enable the Managed Free Ruleset. Paid-plan customers should check that the Managed Ruleset deployment is in block mode, using the ruleset ID in the table above. Cloudflare says it will continue to update the rules as new techniques emerge, and it points readers to its changelog for new rules.

Reviewing blocked requests #

The advisory says to open Security > Security Analytics > Events to analyze blocked requests. You can filter by the rule IDs listed in the advisory and inspect the matched request, the action, and the path. According to the advisory, events identify whether a managed or custom rule produced the action.

The advisory does not explain how to interpret event volume, and this article does not infer a meaning from it. Use the events to confirm which rule matched and on which path, then compare those paths with the traffic your application is expected to receive. That comparison is the basis for deciding whether the Managed Ruleset scope needs narrowing.

Response-phase protection and its limits #

The php2shell managed protections are the first managed detections Cloudflare has released using full transaction detection. That capability evaluates a request together with the origin's response. The companion article, Introducing full transaction detection for Cloudflare WAF, describes the response fields and the response rules that act on them. It states that a response rule can replace the origin response with a WAF block page or a custom response before the response reaches the requester.

The same article states a limit: response rules cannot undo actions that have already been performed at the origin. The php2shell advisory lists remote code execution and data exposure among the possible outcomes of the flaws. The sources state both points separately, and they do not explain how the two relate for any particular deployment. A response-phase block should therefore be read as controlling what reaches the requester, not as reversing server-side effects.

The full transaction article lists three response fields: cf.waf.signature.response.confidence, cf.waf.signature.response.categories, and cf.waf.signature.response.ref. It states that paying customers can use these fields in custom response rules, and that response-body rules are not yet available. It also says Cloudflare is rolling out the response fields to all accounts, and that customers without access should contact their account team.

Deployment timing as stated by Cloudflare #

The advisory gives a timeline for the protections. It states that Cloudflare has developed and deployed WAF protections since early October 2026, and that these protections were deployed about 9 hours ahead of public disclosure. It also states that starting October 21 at 3:02 am UTC, customers using the free or paid WAF were protected by default against php2shell.

The advisory says Cloudflare observed attackers mutating the attack payload to try to bypass its protections. It reports that Cloudflare tracked the volume of matches and cross-referenced them with the rule logic. The advisory also says Cloudflare's security analysts will continue monitoring attack activity and will update rules when new techniques and variations emerge, with updates listed in the changelog.

These statements describe what Cloudflare reports about its own deployment. They do not establish whether any particular origin server was targeted or compromised, and the sources do not report an assessment of that kind for individual customers. For a given application, the relevant evidence is the server's PHP version and the events in your own analytics.