Cloudflare says attackers tried to change PHP2Shell requests to get past its web application firewall while PHP servers faced two runtime flaws that can lead to code execution. Its managed protections were enabled for free and paid WAF customers before public disclosure. A related upload-progress flaw has a narrower WAF rule: sites that renamed the PHP upload-progress field fall outside that rule.
As of October 29, teams running PHP behind Cloudflare have two jobs: verify the edge rules and update the PHP workers at the origin. The PHP CNA records for CVE-2026-109618 and CVE-2026-109619 list first fixed upstream versions on four maintained branches. Both records carry CISA exploitation annotations and an October 26 addition to its Known Exploited Vulnerabilities catalog. Cloudflare says it saw attack traffic against customers as the disclosure unfolded.
PHP cleanup leaves unsafe memory
The PHP project describes CVE-2026-109618 as an out-of-memory cleanup failure. PHP aborts a request after running out of memory, then cleanup can read state that was never properly initialized. Under the conditions described by the CNA, that unsafe memory handling can lead to remote code execution. The record identifies versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on their respective branches.
CVE-2026-109619 involves global state that still points into request memory after PHP frees it. A later request handled by that worker can encounter the stale reference. The PHP CNA gives the same first-fixed upstream versions and describes remote code execution as a possible result. Check the running worker build to find the PHP version serving requests; the application and its plugins have their own versions. A WordPress or Magento code update alone leaves the runtime in place.
Cloudflare says attackers mutated requests during disclosure and that its protections began running by default at 03:02 UTC on October 21, about nine hours before public disclosure. Cloudflare describes the flaws as affecting PHP web servers from 5.4 onward; the PHP CNA records enumerate affected upstream releases on the 8.2, 8.3, 8.4 and 8.5 branches. For older or distribution-maintained builds, obtain the maintainer’s patch status for these two CVEs before treating an origin as updated.
Cloudflare reads both HTTP directions
A request filter sees what a visitor sends. Cloudflare says some PHP2Shell attempts need the origin response to distinguish malicious behavior from ordinary traffic. Its full-transaction detection combines request and response signals from the same HTTP exchange, then a matching response rule can stop the origin’s reply before it reaches the requester. The web server has already processed that request at this point. Blocking the reply protects delivery of that response; installing fixed PHP removes the vulnerable runtime behavior.
Cloudflare placed the request rules in the Cloudflare Managed Free Ruleset, ID 77454fe2d30c4220b5701f6fdfb893ba, for Free customers, and the Cloudflare Managed Ruleset, ID efb7b8c949ac4650a09736fc376e9aee, for paid plans. It says the Managed Response Firewall Default was deployed automatically on all plans. Paid-plan operators should confirm the managed ruleset is in block mode; every operator should check Security > Security Rules for the response-rule deployment.
The October 23 update describes a separate PHP session upload-progress issue, CVE-2026-115560, affecting even the then-patched 8.5.12 release. Cloudflare says rule number 6 in its PHP Remote Code Execution Attack set covers known attempts when session.upload_progress.name retains its default value. Its wording is direct: “Customers who have changed session.upload_progress.name are not covered by the WAF rule.” The rule IDs are 19373a83abb840e18ab3ce5a7975ce1b in the Free ruleset and 4148ae686fdb4d01be673fab9d9c073d in the paid ruleset. Cloudflare says the PHP project plans to fix that related issue in its next regular release. Inspect the actual upload-progress setting at each PHP origin before relying on that particular WAF coverage.
Match edge events to origins
Start with Cloudflare Security > Security Analytics > Events. Filter for the applicable rule IDs, then read the matched request, action and path. A match with an observe-only action calls for a block-mode review on paid deployments. The events also identify managed versus custom rule actions; a custom rule with a similar name is a different deployment. Check Security > Security Rules to confirm the response rules are active for the zone carrying that site’s traffic.
Map each public PHP application to the PHP runtime and worker that actually serves it. Record the installed upstream version or distribution package build and the vendor’s backport notice, then upgrade affected upstream branches to at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12 as applicable. Restart the serving workers after deployment and verify the build on the origin. Keep the WAF enabled while making that change. Where a hosting provider controls PHP, request the provider’s installed-build and patch evidence for both CVEs.
Verify the WAF and PHP workers
For a Cloudflare-fronted PHP site, confirm its managed ruleset action is block, its Managed Response Firewall Default is active, and its PHP worker runs a fixed or vendor-patched build. Check session.upload_progress.name separately: a changed value falls outside Cloudflare’s stated rule coverage for CVE-2026-115560. Review edge events alongside origin error and worker logs when a PHP2Shell rule matches; the edge action describes Cloudflare’s handling of that transaction, while origin evidence guides the investigation of a server that processed it.
After updating, compare a fresh origin-side version or package-changelog check with the deployment record and verify that the serving workers restarted. Then return to the zone’s security rules and events to confirm the intended ruleset remains in block mode and the response detection remains deployed. Those are two different checks because the edge can filter a request while an older worker still runs at the origin.