Does Cloudflare or a WAF Protect You From PHP2Shell?

Partly. A WAF can block the exploit requests its rules recognize, but coverage differs by vendor, rule version and mode. Cloudflare, AWS and Sucuri each describe their own protections in their own notices, and each still says to patch PHP.⁠¹⁠²⁠³ Keep the WAF on, confirm it blocks instead of logging, close every path to your origin that skips it, and install the fixed PHP build.⁠⁴

The complete PHP2Shell guide covers both flaws. This article answers one question: does a WAF in front of your site count as protection?

What "protected by default" claims

Cloudflare says customers on its free or paid WAF were "protected by default against php2shell" from 03:02 UTC on 21 October.⁠¹ Paid-plan customers on Professional, Business and Enterprise are asked to confirm that the Managed Ruleset runs in block mode.⁠¹

I found no vendor that says a WAF alone is enough. Every notice I opened tells readers to patch PHP. So "I'm behind Cloudflare, so I'm covered" is a reading of "protected by default", not something I can quote from anyone.

The strongest case for the WAF

The case is real. Cloudflare says its rules went live about nine hours before disclosure, on every plan with the WAF deployed, Free included.⁠¹ PPC Land notes the post does not say which event it counts as disclosure.⁠⁵ PHP's own release came at 14:00 UTC, just under eleven hours after the rules went live.⁠⁴ Either way, the rules were on before most site owners read the news.

Cloudflare shipped seven rules in its free ruleset, seven in its paid ruleset and a response rule that inspects the origin's reply as well as the request.⁠¹ AWS says customers on the default version of its PHP rule group are protected automatically.⁠² Hadrian reported that most of the attacks it saw abused PHP's session upload-progress path, the path these rules aim at.⁠³

For a site on PHP that cannot be upgraded this week, a WAF can be a useful interim layer that needs no change on the server. How much it helps depends on whether its rules cover the flaw, whether it is in blocking mode and whether all relevant traffic passes through it.

What the vendors say, and what is only reported

The rows below do not carry equal weight. Cloudflare, AWS and Sucuri are the vendors' own notices or documentation. Barracuda is general product documentation, not a PHP2Shell statement. The Fastly, Bunny, Imunify360 and Azure Front Door rows are secondary reporting and are marked as reported in the table. Those claims date from 21 to 23 October. I did not re-verify them on 4 November, so a limitation listed here may no longer hold.

PPC Land adds a point about Cloudflare's response rule. A response rule inspects what the origin sends back, so the request has already reached the origin by then, and the post does not say what the origin did with it.⁠⁵ Blocking a response is not the same as stopping the server from processing the request. Neither PPC Land nor Cloudflare says whether any request was successfully exploited that way, and this article does not claim one was. The point concerns the response rule only, not Cloudflare's other rules. Hosts that run the WAF for you split the same way: edge rules first, fixed builds later. How hosting providers responded has the timeline.

I searched on 4 November 2026 for an independent test of any vendor's managed rules against PHP2Shell, including mutated payloads. I found none. I found single-author lab write-ups and vendor statements. Nobody has published a measured bypass rate, so nobody can say how often the rules miss.

The origin problem

A WAF only protects traffic that passes through it. Sucuri puts it plainly: "WAF protection only works when requests pass through the firewall."⁠³ If attackers can reach your origin directly, they can send requests to PHP without meeting the rules.⁠³ PPC Land notes that Cloudflare's post does not address origins reachable outside its proxy.⁠⁵

The fixes come from the vendors' own documentation:

• Sucuri's checklist: restrict direct IPv4 and IPv6 access to the origin, accept web traffic only from the firewall's addresses, remove old DNS records and alternate hostnames that expose the origin, protect staging and backup copies, and check unprotected subdomains and alternate ports.⁠³
• Cloudflare's documentation: use proxied DNS records, audit DNS-only records for origin addresses, and rotate origin IPs after onboarding.⁠¹⁰ It rates authenticated origin pulls and Cloudflare Tunnel "very secure". It rates allowlisting Cloudflare's IP ranges "moderately secure" and notes it is vulnerable to IP spoofing.⁠¹⁰

Opinion Test only systems you own or are authorized to test, and use a test or maintenance window where you can. A useful direct-origin test sends the Host header and TLS server name your site expects, covers every origin IPv4 and IPv6 address, old hostnames and non-standard ports, and is read against your firewall rules. A refused connection to a bare IP address does not prove the origin is unreachable, because a default virtual host, an alternate hostname or another route may still serve your application.

The strongest objection to this view

"Patching is slow or impossible for many sites, so telling people a WAF isn't enough doesn't help them."

Agreed on the first half. A WAF is a useful interim layer for a site that cannot patch today. Use it well:

• Confirm it blocks. Cloudflare's paid plans need block mode confirmed. AWS needs the default or latest rule-group version. Fastly needs the opt-in.⁠¹⁠²⁠⁸
• Read the matches. Cloudflare says to filter Security Analytics by rule ID.⁠¹
• Lock the origin, as above.⁠¹⁰
• Add request limits at the proxy. PHP suggests limits on decoded request size, field count, multipart parts, header count and nesting depth, including for requests with no usable Content-Length.⁠⁴
• Turn off session upload progress in PHP at server level. PHP lists it for CVE-2026-109619 and recommends it for CVE-2026-115560.⁠⁴

On PHP 8.1 or older with no vendor backport, workarounds when you can't patch lists the PHP settings that go with the WAF.

Opinion A WAF is a good first hour and a poor last step. PHP states that updating is "the only safe choice", and the vendors' notices agree.⁠⁴

What would change this

Three kinds of evidence would move me toward "covered":

1. An independent test showing a vendor's managed rules block published exploit variants, mutated payloads included, on both mod_php and PHP-FPM.
2. A vendor statement that its rules cover both CVEs, including the out-of-memory path. AWS's changelog now says its PHP rule group detects CVE-2026-109618 directly from version 2.4, which meets this for AWS.⁠⁶ I found no equivalent statement from the others I checked.
3. Measured bypass rates close to zero over time.

CVE-2026-115560 adds a condition. Cloudflare says its WAF covers that flaw only for sites that keep PHP's default upload-progress field name. Customers who changed session.upload_progress.name are not covered.⁠¹

How you'd notice

A WAF hit means an attempt reached the filter. It says nothing about whether the origin is patched. Pantheon blocked more than 60,000 suspicious requests on 21 October at network level alone, and attempts are not compromises.⁠⁸

Your WAF is probably not covering you if any of these is true:

• The ruleset is in log, passive or detection mode.
• The vendor's rule is opt-in or disabled by default, and nobody switched it on.
• A pinned AWS PHP rule-group version predates 2.4 and nothing else in the web ACL, such as the Core rule set's body-size rule, covers CVE-2026-109618.
• Your origin's access log shows client addresses that do not belong to your proxy. Sucuri's checklist exists to close exactly that path.⁠³

If you search Cloudflare events for "PHP", you may find nothing. PPC Land reported the rules under generic names at launch, and Cloudflare's post now lists PHP-named labels.⁠⁵⁠¹ Filter by rule ID instead.

Do this

Do today

1. Check which PHP the origin runs and patch the PHP runtime itself, then restart every worker.
2. Confirm the WAF blocks: Cloudflare Managed Ruleset in block mode, the AWS PHP rule group on the default version or a pinned 2.4 or later, Barracuda in active mode, Fastly and Azure rules switched on.
3. If you are authorized to test the system, check from outside your network whether the origin answers web requests that skip the WAF. Try each origin IPv4 and IPv6 address, old and alternate hostnames and non-standard ports, send the Host header and TLS server name your site expects, and compare the result with your firewall's allow rules. A refused connection to a bare IP proves little.
4. If you cannot patch today, set session.upload_progress.enabled=0 at server level and apply the proxy limits above.

Do this week

5. Read your rule matches as attempts. What to look for in WAF logs covers what separates a blocked probe from a real hit.
6. Audit DNS-only records, alternate hostnames and staging copies for origin exposure. Rotate the origin IP if it leaked.
7. On AWS, move off a pinned rule-group version and subscribe to AWS's managed-rules notification topic, as its bulletin advises.⁠²
8. Ask your host in writing which PHP build runs your site and whether the WAF is in block mode.

Can wait

9. Re-check your vendor's notice for coverage of the out-of-memory path and CVE-2026-115560.
10. Re-read PHP's advisory when the CVE-2026-115560 fix ships.

CISA added both PHP2Shell CVEs to its Known Exploited Vulnerabilities catalog on 26 October and updated its PHP alert.⁠¹¹ The bulletin I opened states no remediation due date, so check the catalog entry for one. CISA says BOD 26-04 applies only to federal civilian agencies and encourages all organizations to prioritize KEV vulnerabilities.⁠¹¹ The listing alone does not say how many sites were compromised.