Two flaws in PHP can hand an unauthenticated attacker remote code execution, and PHP says a demonstrated attack on Apache with mod_php fires before the website’s own code runs. Cloudflare switched on default protection against both at 03:02 UTC on October 21, about nine hours before public disclosure by its own count. The head start mattered, and it still leaves gaps that no firewall rule can close.
What php2shell Is
php2shell is the name for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on the CVSS v4.0 scale by PHP’s security team. In the first, PHP runs out of memory partway through a request and leaves some internal data uninitialized, and request cleanup may then treat that data as valid. In the second, internal state from one request can outlive the memory behind it, and a later request handled by the same worker may use that stale state before PHP resets it. Cloudflare says the flaws may allow an attacker to cause denial of service, remote code execution and data exposure.
PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it considers the risk highest for mod_php. The advisory for the first flaw adds that no complete exploit has been demonstrated against PHP-FPM, and its CVSS vector rates attack complexity as high. The PHP Foundation said its security team did not identify any functional exploits at the time of release, although proof-of-concept code had begun to circulate.
Cloudflare says Calif.io, Wiz, OpenAI and Quarkslab disclosed the flaws. Wiz says it reported its findings to PHP on August 24, that PHP acknowledged them on September 21, and that AI models helped throughout the research. PHP shipped fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Cloudflare says the flaws affect all web servers running PHP 5.4 or later. W3Techs puts PHP at 69.3 percent of the websites whose server-side language it can identify, as of October 22, and Cloudflare names WordPress and Magento among the platforms that depend on it.
Why a WAF Has to Read the Response
An application cannot defend itself against these flaws. Datadog’s reproduction used an unauthenticated POST request that never reached application code, so application-level authentication does not block it. A firewall in front of the server is one of the few places to intervene before patching, but request inspection has limits. PHP’s advisories list multipart techniques among the known ways to trigger the out-of-memory condition and name session upload progress, which is enabled by default, as a trigger for the second flaw. Cloudflare says request data alone does not always provide enough evidence to distinguish an exploit from legitimate traffic.
Cloudflare’s answer is full transaction detection, which it described in a companion post the same day. The capability evaluates a request together with the origin’s response, and when a blocking rule matches, Cloudflare replaces the origin response with a WAF block page or a custom response. The php2shell protections are the first managed detections Cloudflare has released with it. The companion post’s example is a path traversal request for a database configuration file: request inspection can recognize the attempt, but the request alone cannot establish whether the application would expose the file. The response is where that answer shows up.
The design has a limit that Cloudflare states itself. A response rule cannot undo actions already performed at the origin. The implication is that response inspection protects data leaving the server better than it protects the server. Imperva describes one php2shell technique that returns about 67 KB of server memory in a Set-Cookie header carrying the session ID, the kind of leak response-side detection targets. Code that has already run on the origin is another matter. Cloudflare has not published what its php2shell signatures look for, so any link between them and that leak is inference.
What Each Plan Gets
Cloudflare says free and paid WAF customers were protected by default from 03:02 UTC on October 21. Free customers need to do nothing, because the rules sit in the Cloudflare Managed Free Ruleset. Professional, Business and Enterprise customers get seven rules in the Cloudflare Managed Ruleset, and Cloudflare asks them to review the deployment and confirm it runs in block mode. Every plan, free included, also gets a response-side rule in the Cloudflare Managed Response Firewall Default ruleset that blocks high-confidence signatures by default.
The labels are generic. The rules read “Anomalous Execution” followed by a number from one to seven, with no mention of PHP or the CVEs. Cloudflare’s post says the rule descriptions will be updated soon and lists the rule IDs so teams can filter matches under Security Analytics. Until the labels change, a security team scanning its dashboard cannot tell from the names which rules cover php2shell.
The Clock Started Before Disclosure
The sequence matters. CVE identifiers began circulating online around 15:00 UTC on October 20 with a wrong release time and a wrong CVSS score of 10.0, according to the PHP Foundation, which says no technical details had leaked. PHP posted an advance notice at 19:33 UTC and moved its release up from October 22 to 14:00 UTC on October 21. The foundation adds that Calif then accidentally published a video of its proof of concept, which helped others develop their own proof-of-concept code faster.
Cloudflare’s rules went live at 03:02 UTC on October 21. Cloudflare counts its lead as about nine hours, but PHP’s release landed at 14:00 UTC, which makes the gap closer to eleven. Cloudflare says it had been developing protections since early October, working with the PHP Foundation, OpenAI, Wiz and others. It was not the only vendor with early notice. PHP says Linux distributions and LTS vendors received the patches in advance, and Imperva says the researchers briefed it confidentially before disclosure and that its Cloud WAF customers are protected out of the box.
Attackers did not wait for the leak. Amazon Threat Intelligence reported that its MadPot honeypot logged an exploitation attempt dated October 17, four days before disclosure, and said it remains unclear how the actor obtained exploit information. Cloudflare says it observed attack traffic against its customers and saw attackers mutating payloads to get around its rules, though it published no counts.
Vendors describe attempts more than successes. watchTowr said on October 21 that it was observing active exploitation attempts against both flaws and did not say any succeeded. Amazon says php2shell is now being broadly exploited in the wild, while also saying it is unclear whether the attempts it saw would succeed on real systems. The Hacker News reported that no source had confirmed a successful break-in of a specific server as of its October 21 update. For an unpatched server outside Cloudflare’s protection, the earliest known attack attempt predates disclosure by four days, and Amazon’s guidance reflects that: start investigations from the earliest known exploitation, not from the disclosure date.
Patching Is Still the Only Complete Fix
Cloudflare says plainly that customers should patch PHP even with the WAF in place, and it describes its rules as an additional layer of defense in depth. The flaws sit in the PHP runtime, so updating website code or plugins does not fix them, and customers on managed hosting should ask their provider to apply the security update. PHP’s release notes say there are no complete mitigations and that updating is the only safe choice. A WAF also inspects only the traffic routed through it, so an origin server reachable by another route gets no cover.
Patching carries its own friction. PHP 8.1 and older no longer receive updates from the project, and 8.2 reaches end of life on December 31, 2026. For 7.4, 8.0 and 8.1, the security team provided minimal source backports for people building from source or without an LTS vendor.
Laravel Forge warned customers that its automatic security updates do not patch PHP, because Forge installs PHP from a dedicated package repository outside Ubuntu’s own security channel. Long-running processes such as queue workers keep the old PHP until someone restarts them.
What Operators Should Take From It
The signal worth watching is the response side. Cloudflare says it will expand coverage over time to include detecting data exposure and exfiltration signals, which suggests its managed rules are moving from judging requests toward judging what servers send back. php2shell fits that pattern, because on the memory-disclosure path the evidence shows up in the reply.
The implication for operators is straightforward. Inventory every PHP version in production, patch the supported branches, plan a move off 8.1 and earlier, and restart long-running workers after the update. Amazon also advises searching form-upload POST requests for the string PHP_SESSION_UPLOAD_PROGRESS and checking servers for unexpected process execution or file changes. The WAF lowers the odds while that work happens, and Cloudflare itself says attackers are already reshaping their payloads against it.
Any similar runtime flaw will test the same arrangement: vendors with advance notice, a leak that shrinks the window, and customers who still have to do the patching. Clearer rule names and published attack counts would let those customers judge how much time a head start bought them.
The post Cloudflare Deployed php2shell Protection Hours Before Disclosure. Here’s What the Head Start Doesn’t Cover appeared first on DataFLOQ.
