Cloudflare today said its web application firewall has been blocking attempts to exploit php2shell, the pair of PHP runtime vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619, since 3:02 am UTC on October 21, 2026. According to a blog post by Daniele Molteni, Dan Jones and Kuber Nandwani, the rules reached customers on every plan with the WAF deployed, including Free, about 9 hours ahead of public disclosure. Cloudflare also said the flaw leaked before the official release date and that it observed attack traffic aimed at its customers.

In Short

Cloudflare, which sits in front of millions of websites, switched on filters that try to stop attackers from using two newly disclosed holes in PHP, the software behind sites such as WordPress stores and blogs. Website owners on Cloudflare got the filters automatically, and Cloudflare says attackers were already trying to get through and changing their attacks to dodge the rules. The filters are a second layer only, because Cloudflare itself says the real fix is updating PHP on the server.

Same flaws, a different vantage point

The vulnerabilities are the same ones the US National Security Agency and CERT-EU, the cybersecurity service of the EU institutions, warned about earlier today. The CVE numbers in Cloudflare's post match those in CERT-EU's Security Advisory 2026-018, and the name php2shell matches the GitHub repository maintained by the Dutch National Cyber Security Centre that CERT-EU cites for tracking third-party software embedding PHP.

What Cloudflare adds is the view from the network edge. The agencies described the flaws and the patches. Cloudflare describes what it did at the layer between visitors and origin servers, what it says it saw in that traffic, and what it says it cannot do on behalf of site owners.

All of that comes from the vendor. Cloudflare sells the WAF protection it describes, and the post's observations about attack traffic have not been independently verified. The post gives no counts of blocked requests, attacking IP addresses or affected customers.

Who disclosed the flaws

Cloudflare's post names the researchers, which neither agency document did. "Today, Calif.io, Wiz, OpenAI and Quarkslab disclosed two vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and known as php2shell," according to Cloudflare. The post links to disclosure pages from the PHP project, the PHP Foundation, OpenAI and Wiz. PPC Land has not reviewed those linked pages for this article.

Cloudflare describes itself as having "been part of a coordinated effort to deploy mitigations to protect the Internet, working with PHP foundation, OpenAI and Wiz among others." The post does not say when Cloudflare was first notified.

Where Cloudflare's account differs from the advisories

Several details in the Cloudflare post do not line up with CERT-EU's advisory or the NSA statement. None is necessarily an error, but each changes how the event reads.

Affected versions. Cloudflare says the vulnerabilities "affect all web servers running PHP 5.4 or later." CERT-EU lists the supported 8.2, 8.3, 8.4 and 8.5 branches before their fixed releases, plus end-of-life branches described as PHP 8.1 and older, and mentions source backports only for 7.4, 8.0 and 8.1. Cloudflare's 5.4 floor is a specific lower bound that CERT-EU does not state. The Cloudflare post does not list the fixed version numbers; it points administrators to the PHP advisory instead.

Impact. CERT-EU scores each flaw at CVSS 9.2 and describes both as allowing unauthenticated remote code execution. Cloudflare gives no score. It says the pair "may allow an attacker to cause denial of service, remote code execution, and data exposure." Its table describes CVE-2026-109619 as a flaw through which PHP may "access memory that is no longer valid and expose sensitive data," without repeating the code execution label CERT-EU attached to that specific CVE.

Exploitation. This is the sharpest difference. CERT-EU said circulating proofs of concept raised "the likelihood" of exploitation, and neither agency reported confirmed attacks. Cloudflare states that "the vulnerability was leaked before the official release date and we observed attack traffic targeting our customers." It does not say when the leak happened, what form it took or when the first attack traffic appeared.

Disclosure timing. Cloudflare says its protections went live at 3:02 am UTC and were "deployed about 9 hours ahead of public disclosure." It does not say which event it counts as public disclosure. CERT-EU puts the PHP team's release of fixes at 13:30 UTC on October 21, which by PPC Land's calculation is 10 hours and 28 minutes after 3:02 UTC. A 9-hour gap would point to roughly midday UTC, so Cloudflare may be measuring against a different event, such as a researcher publication. CERT-EU also notes that the PHP project gave advance notice of the security release on October 20.

What Cloudflare deployed

Two managed rulesets, seven rules each

Free customers received the rules through the Cloudflare Managed Free Ruleset, ruleset ID 77454fe2d30c4220b5701f6fdfb893ba. "Free customers don't have to take any actions to enable the protection," according to Cloudflare. The seven rules are labelled Generic Rules - Anomalous Execution - 1 through 7, with these IDs:

  • 1: 4e315666e8e344cdb64119a3b5ccf32f
  • 2: 00c10e6cc4da4bd08722adeebcd95984
  • 3: 48ddf592361e4fdb97a8a85982dab691
  • 4: 3556683d512a47f2937899c524b1a4c6
  • 5: da07c85852e34625bb478496302ede46
  • 6: 19373a83abb840e18ab3ce5a7975ce1b
  • 7: 07f0b6ddaabf40b1b2042dade8d613fa

Paid plans received seven rules with the same descriptions in the Cloudflare Managed Ruleset, ruleset ID efb7b8c949ac4650a09736fc376e9aee, under different IDs:

  • 1: c1d409ad838f47f59446f21cc438d5dd
  • 2: f9a45927414245e3a64bb12d0a0c2f64
  • 3: 771c654ae1154d4daa72f4e1545d163c
  • 4: 217005865f0145f392300bac212afcc9
  • 5: 38efdb17ea594501bb55a1d71867b12e
  • 6: 4148ae686fdb4d01be673fab9d9c073d
  • 7: 1389aa259617437392ce149c48143645

The descriptions are generic, and Cloudflare's post carries the line "Note: rule descriptions will be updated soon." Nothing in the rule names ties them to PHP or to either CVE, which matters for anyone later searching a security log for php2shell by name rather than by ID.

A default that depends on the plan

The post is not entirely consistent about what "by default" means for paying customers. Its introduction says that from 3:02 am UTC, "Cloudflare customers using our free or paid WAF were protected by default against php2shell," and that the protections "are available and deployed automatically on all plans with WAF deployed, including Free users." Its closing section says customers "using our Managed Ruleset are protected by default."

The paid-plan section, however, asks Professional, Business and Enterprise customers to check their own configuration and "confirm it's deployed block mode." That instruction implies a paid deployment may not be blocking. The post does not say what share of paid zones run it in block mode, so the scope of default protection on paid plans cannot be read from the document.

Full transaction detection

The more unusual part of the deployment concerns responses rather than requests. "Protecting against php2shell required more than standard request-based rules," according to Cloudflare. "Request data alone does not always provide enough evidence to distinguish an exploit from legitimate traffic. The origin's response adds context, helping identify whether an exploit succeeded while reducing the risk of false positives."

To do this, Cloudflare built what it calls full transaction detection, "a new Cloudflare WAF capability that combines signals from the request and response within the same HTTP transaction." The practical consequence, according to the post, is that "response rules can then block a matching origin response before it reaches the requester." Cloudflare says "the php2shell protections are the first managed detections we have released using this capability." A separate Cloudflare post, "Introducing full transaction detection for Cloudflare WAF," by Daniele Molteni, Elie Roudninski and Nick Downie, is dated the same day.

One rule sits in the new Cloudflare Managed Response Firewall Default, deployed "for customers on all plans, including Free": Default block for High confidence Signatures, rule ID afffe22785674c80a31875c848d2242a.

The design reflects where Cloudflare sits. As a reverse proxy, the service already handles both the request travelling to a customer's server and the reply coming back. Inspecting the reply lets it judge whether a request actually triggered something on the origin, rather than guessing from the request alone. It also means the detection only stops the response: by the time a response rule fires, the request has already reached the PHP server. The post does not say what happens on the origin in that case, and a response-side block does not undo code that has already run there.

Attackers changing payloads

Cloudflare says attackers adapted quickly. "We observed how attackers were mutating the attack payload to try to bypass our protections by tracking the volume of matches and cross-referencing with the rule logic," according to the post. Its analysts "continue monitoring attack activity and update the rules when and if new techniques and variations emerge in the hours and days ahead," with new rules tracked in the WAF changelog.

The post does not say whether any mutation succeeded in getting past the rules before an update, or how many rule revisions followed the 3:02 UTC deployment.

Development timeline

According to Cloudflare, it "has developed and deployed web application firewall (WAF) protections since early October 2026." The wording does not separate development from deployment, and the post gives only the single deployment timestamp of 3:02 am UTC on October 21.

The flaw as Cloudflare explains it

Cloudflare's technical description is written for a general audience and is less detailed than CERT-EU's, which cited longjmp(), the memory_limit directive and form-based uploads. "The two vulnerabilities involve how PHP handles memory when something goes wrong while processing a HTTP request," according to Cloudflare. 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 the memory safely."

According to the post, an attacker can send crafted HTTP requests to create those conditions. "Large requests are one way to put memory under pressure, but the problem goes beyond consuming server resources," Cloudflare wrote. "By manipulating the data PHP encounters in this invalid memory, an attacker may be able to crash a PHP process, expose sensitive information, or execute code provided by the attacker."

The post separates the two CVEs by when the unsafe access occurs:

  • 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."

These descriptions are consistent with CERT-EU's account of an out-of-memory abort and of stale state surviving into a later request on the same worker.

What stays with the site owner

Cloudflare is direct that its rules are not a fix. "Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation," according to the post.

The company also spells out a point that matters for anyone running a content management system. "These flaws are in the PHP runtime, so updating website code or a plugin(s) alone does not fix these vulnerabilities," according to Cloudflare. "Administrators need to update the PHP software running their applications." For sites where a hosting provider manages PHP, the post says the provider has to apply the security update.

Cloudflare adds that "restricting unnecessary uploads and limiting upload sizes can also reduce exposure, but these measures do not replace the PHP fix." That tracks CERT-EU's own stopgaps, which included a low post_max_size, but Cloudflare does not reproduce CERT-EU's specific settings.

For reviewing what the rules caught, Cloudflare points to Security > Security Analytics > Events in its dashboard, filtered by the rule IDs, where matched requests, actions and paths can be inspected. According to the post, events show whether the action came from a managed or a custom rule, and customers can narrow the scope of the Managed Ruleset to the parts of an application where it is relevant.

There is also a structural limit the post does not discuss. A WAF only inspects traffic that passes through it. A PHP server reachable directly by IP address or by an unproxied hostname receives requests that never touch Cloudflare's rules. PPC Land documented a version of this gap in April, when a Shopify merchant's Cloudflare rules had no effect on bots that went straight to the store's myshopify.com subdomain, which sits behind Shopify's own Cloudflare account rather than the merchant's.

Why this matters for publishers and advertisers

Cloudflare's post puts PHP's footprint at "almost 70% of websites," linking to W3Techs as the source, and names WordPress and Magento as platforms built on it. For the advertising and publishing industry, that covers content sites, lead-generation landing pages and e-commerce checkouts alike.

The patching record of that population is the reason edge protections matter in the short term. In September, 20i found 88% of WordPress sites running outdated software, with micro-businesses most exposed. Those figures concern WordPress itself, not the PHP runtime, but they describe the same operators, many of whom depend on hosts and agencies to apply server updates. Cloudflare's rules reach those sites without any action on Free plans, provided their traffic is proxied and, on paid plans, the Managed Ruleset is set to block.

Cloudflare has argued about PHP's security model before. In April, the company's EmDash launch set off a dispute with WordPress co-founder Matt Mullenweg after Cloudflare described WordPress plugins as PHP scripts with unrestricted access to the database and filesystem. The php2shell flaws sit below that layer, in the interpreter, and Cloudflare's own post says plugin updates do not address them.

The response-inspection model also fits a pattern in Cloudflare's recent security products, which increasingly rely on watching behaviour over time rather than matching single requests. Its 2026 threat report in March described a critical unauthenticated remote code execution flaw in markdown rendering pipelines scored 9.4. In September, the company opened its Threat Events Platform to all accounts, though custom WAF rules stayed an enterprise feature. And on October 17, PPC Land reported on trust scores for Cloudflare Verified bots, another system built on observed patterns rather than isolated events.

For advertisers, a compromised PHP server is a supply-side problem as much as a security one. Injected scripts and redirects are a standard route for malvertising, and the data exposure Cloudflare describes for CVE-2026-109619 could reach whatever a site stores in memory, including session data and form submissions. The CDN layer that many publishers already use for speed is now, for a period, also the first filter against a runtime flaw that the publisher's own code cannot fix.

What the post does not say

The post leaves several questions open. It gives no figures for attack volume, blocked requests or affected zones. It does not describe the leak it mentions, or say when attack traffic began relative to the 3:02 UTC deployment. It does not say which event it treats as public disclosure, so its 9-hour figure cannot be reconciled with CERT-EU's 13:30 UTC release time from the documents alone. It does not explain what share of paid customers had the Managed Ruleset in block mode. And it does not address origins reachable outside Cloudflare's proxy.

Timeline

Summary

Who: Cloudflare, in a blog post by Daniele Molteni, Dan Jones and Kuber Nandwani, describing protections for its customers. The vulnerabilities were disclosed by Calif.io, Wiz, OpenAI and Quarkslab, according to Cloudflare, and were the subject of NSA and CERT-EU advisories the same day.

What: Seven WAF rules in the Cloudflare Managed Free Ruleset, seven in the paid Cloudflare Managed Ruleset and one rule in a new Managed Response Firewall Default, aimed at the php2shell flaws CVE-2026-109618 and CVE-2026-109619. The response rule uses full transaction detection, a new capability that inspects the origin's reply as well as the request. Cloudflare says the flaw leaked early and that it observed attack traffic and payload mutations.

When: The rules took effect at 3:02 am UTC today, October 21, 2026, which Cloudflare says was about 9 hours before public disclosure. Development started in early October, according to the post.

Where: On Cloudflare's network, for every plan with the WAF deployed, including Free. Paid customers are asked to confirm their Managed Ruleset is in block mode. The flaws themselves sit in PHP servers that Cloudflare says run "PHP 5.4 or later."

Why: According to Cloudflare, request data alone was not enough to separate exploits from legitimate traffic, so it added response inspection. The company says the rules are a defense-in-depth layer only, and that updating the PHP runtime, not website code or plugins, is the fix. The findings and figures come from Cloudflare, which sells the protection described.