php2shell: Cloudflare's Pre-Disclosure WAF Rules and Why Patching Still Matters
Cloudflare deployed WAF rules for the php2shell PHP flaws ahead of disclosure. The bugs sit in the PHP runtime, so patching is still required.
The useful part of this story isn't the WAF rules themselves. It's that php2shell is a pair of flaws in the PHP runtime, which means no amount of application-layer cleanup fixes them, and the edge defenses that blunt them now have to look at what the server sends back, not just what the client asks for.
What was disclosed, and when
On October 21, Calif.io, Wiz, OpenAI and Quarkslab disclosed two vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and known as php2shell. They affect every web server running PHP 5.4 or later. An attacker who sends specially crafted HTTP traffic can potentially cause a denial of service, run code remotely, or expose data.
Two days later, on October 23, the PHP project published a separate informational advisory for a related bug, CVE-2026-115560. It sits in PHP's session upload progress feature and affects fully patched releases, including 8.5.12. The fix will land in PHP's next regular release, so right now there's no patched build to install for that one. Keep it on your radar even if you've already updated for php2shell.
How the memory bugs work
Both flaws come down to memory handling when a request goes wrong. Normally PHP allocates memory for a request, does the work, and releases that memory when it's done. If processing stops unexpectedly, PHP doesn't always clean up safely. The two CVEs exploit that gap in different ways.
Vulnerability | What goes wrong |
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 and expose sensitive data. |
Large requests are one way to put memory under pressure, but the real issue is what happens afterward. By shaping the data PHP reads from that invalid memory, an attacker may be able to crash a process, leak sensitive information, or run attacker-supplied code. The second bug is the more unusual one, because it depends on state persisting between requests in the same process. That's why long-running PHP workers deserve a closer look during triage.
The scale is what makes this worth attention. PHP is used by roughly 70% of websites, and it sits underneath platforms like WordPress and Magento. A runtime flaw of this type can reach a very large number of applications without any of them having a bug of their own.
Why a WAF rule alone wasn't enough
Blocking php2shell took more than request-based pattern matching. A request can look ordinary on its own, and plenty of legitimate traffic resembles an exploit attempt. What separates a successful exploit from a harmless request is often what the origin returns. An unusual response after a suspicious request is a much stronger signal.
Cloudflare addressed this with a new capability called full transaction detection. It combines signals from the request and the response within the same HTTP transaction, and response rules can block a matching origin response before it reaches the client. Cloudflare says the php2shell protections are the first managed detections built on this approach. Teams that have only ever thought about WAFs as request filters should note that this changes the design space. Response inspection costs more to run, but it can cut false positives on rules that would otherwise be too blunt to enable.
The rollout timeline
Cloudflare said it started developing and deploying WAF protections in early October and had them in place about nine hours before public disclosure. Starting October 21 at 3:02 am UTC, customers on free or paid WAF plans were protected by default. Cloudflare also reported seeing attack traffic aimed at its customers, and said attackers were mutating payloads to try to get past the rules. The team tracked match volumes and compared them against rule logic to see those changes.
That sequence matters for anyone reviewing logs. Exploitation activity appeared around the disclosure window, not after it, so a clean-looking dashboard doesn't prove a server was never probed. It's worth checking the server side too.
What Cloudflare customers have to do
The protections are deployed automatically on all plans with WAF enabled, including Free. Cloudflare's rule sets differ by tier:
Free customers get seven rules under the Cloudflare Managed Free Ruleset (Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba). No action is needed to turn them on. Paid Professional, Business and Enterprise plans get seven matching rules under the Cloudflare Managed Ruleset (Ruleset ID efb7b8c949ac4650a09736fc376e9aee). Those customers should confirm the deployment is set to block mode, not log mode. The full rule IDs are in Cloudflare's managed rules documentation, and new variants will appear in the changelog as Cloudflare's analysts add them.
Response rules come through the Cloudflare Managed Response Firewall Default, which is deployed automatically across plans, including Free. You can confirm it's active under Security > Security Rules.
To review what's been blocked, go to Security > Security Analytics > Events and filter by the rule IDs. Each event shows the matched request, the action taken, and the path, and it indicates whether a managed or custom rule fired. If a managed rule is generating noise on parts of an application where it doesn't belong, you can narrow its scope to the relevant endpoints in the dashboard.
Patching is still the fix
Here's the thing: the WAF is a layer, not the remedy. Because the flaws live in the PHP runtime, updating application code, a framework, WordPress, or individual plugins won't close them. The PHP software itself has to be updated. If a hosting provider manages PHP for you, you'll need to ask them to apply the update.
The fixed upstream versions listed in the advisory are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end-of-life upstream, so teams still on those branches need either a vendor backport or an upgrade to a supported version. The PHP project's advisory is the reference for affected versions and remediation steps, and it's worth re-reading in case it changes before your rollout.
Distribution packages are a trap for quick version checks. Debian, Ubuntu, RHEL and Alpine often backport security fixes without bumping the upstream version string, so running php -v alone can mislead you. Check the package changelog for the CVE IDs instead. Be careful with third-party repositories too. Cloudflare's guidance on the advisory notes that some community repos may not ship same-day updates, so verify before assuming you're covered.
Restarts matter as much as upgrades. Old processes keep running vulnerable code until they're restarted. That includes PHP-FPM pools, Apache with mod_php, FrankenPHP, LiteSpeed, and long-running workers such as Laravel Octane, RoadRunner or Swoole. mod_php carries the most exposure, since the exploit path can trigger before any application code runs.
If you can't patch right away
Some teams will need stopgaps. Restricting unnecessary uploads and limiting upload sizes reduces exposure, and so does enforcing request size, field count and header limits at the web server or proxy. For the memory-exhaustion path, the guidance includes setting memory limits at the container or cgroup level rather than through RLIMIT_AS or RLIMIT_DATA, and keeping post_max_size low. For CVE-2026-109619, setting session.upload_progress.enabled=0 closes the upload progress path, and on PHP 8.5, fatal_error_backtraces=0 is another hardening step. Set these in php.ini or the pool configuration, not in ini_set() or .user.ini, and restart every worker afterward.
None of these replace the patch. They buy time.
Cloudflare's own guidance for customers is to patch the PHP repositories as soon as possible and keep the WAF enabled as an extra layer. Its analysts say they'll keep updating rules as new variants emerge in the days ahead. The CVE-2026-115560 fix should follow in PHP's next regular release, and that's the one to plan for next.
