Which WAFs Block PHP2Shell? Cloudflare, AWS, Fastly, Imperva and More

As of 23 October 2026, Cloudflare, AWS WAF, Fastly, Imperva, Sucuri, Barracuda, Google Cloud Armor, Microsoft Azure and Vercel have all published PHP2Shell protections or guidance. Akamai has published nothing we could find, and F5's article could not be read. Coverage differs: some rules switched on by themselves, some are opt-in, and some depend on your plan.

The direct answer: several WAFs block the known PHP2Shell attack patterns, but none of them fixes the flaw. A WAF is a layer, not a fix. Every vendor below says to update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a vendor build with the same patch.

A web application firewall (WAF) inspects web requests before they reach your server and blocks ones that match known attacks. Below: what each vendor published, what is on by default, and what is not covered.

What a WAF Can and Cannot Do for PHP2Shell

PHP2Shell is a pair of memory-safety bugs in the PHP engine itself, not in WordPress or any other app. A WAF can recognize request patterns that published exploits use and block them before PHP sees them. It cannot change the vulnerable code on your server, and it can miss new variants.

The vendors say so themselves:

• Cloudflare: "Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation."
• AWS: "AWS WAF is a defense-in-depth control in this situation, not a replacement for the PHP upgrade."
• Barracuda: "Patching PHP is the only complete fix for PHP2Shell," and "A WAF in monitoring or passive mode records traffic but does not block it."

Use a WAF to cut risk while you patch, and keep it on afterwards. PHP's own settings for buying time are in our guide to PHP2Shell interim mitigations.

Coverage at a Glance

Cloudflare

Cloudflare's PHP2Shell post says that "Starting on October 21 3:02 am UTC, Cloudflare customers using our free or paid WAF were protected by default," about nine hours before public disclosure. Free customers "don't have to take any actions." Pro, Business and Enterprise customers should "review your Managed Ruleset deployment to confirm it has deployed block mode."

The rule names changed over time. On 21 October the seven rules appeared in Cloudflare's changelog as "Generic Rules - Anomalous Execution - 1" through "- 7." On 22 October Cloudflare renamed them "PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619)" through "#7," with "Detection logic and rule actions" unchanged. If you search your 21 October events for "PHP," you will not find them under that name. Rule IDs, the response-side rules and dashboard steps are in our PHP2Shell and Cloudflare guide.

AWS WAF

The AWS WAF managed rule group changelog shows three releases of the PHP application managed rule group (AWSManagedRulesPHPRuleSet):

1. 21 October, version 2.3: a new PHP2Shell_BODY rule for CVE-2026-109619. For CVE-2026-109618, AWS pointed to the SizeRestrictions_BODY rule in the Core rule set, which blocks request bodies over 8 KB.
2. 22 October, version 2.4: a new PHP2Shell_BODY_Extended rule. "This rule group now detects CVE-2026-109618 directly. This supersedes the guidance in the version 2.3 entry."
3. 22 October, version 2.5: "Improved the detection signatures" for both CVEs.

AWS's security blog says it "promoted version 2.3 to the default version globally," so a web ACL that already uses the rule group at the default version has the rule active. Skip the 2.3 advice to cap request bodies at 8 KB if you can: a cap that small blocks normal file uploads, and version 2.4 replaced it. AWS also notes that for apps that use multipart uploads, "AWS WAF reduces risk but does not close the vulnerability."

Fastly, Imperva, Sucuri and Barracuda

Fastly. Fastly's 21 October post says Next-Gen WAF "customers may enable the signal covering both CVE-2026-109618 & CVE-2026-109619," and that "anyone who has opted-in will receive subsequent updates automatically." The post does not say the rule is on by default, so log in and turn it on.

Imperva. Imperva's 22 October post says "Imperva Cloud WAF customers are protected against PHP2Shell out of the box. Elastic WAF customers receive protection following the applicable software update. WAF Gateway customers receive protection following the applicable software and ADC security-content updates." Imperva also suggests turning off OPcache temporarily; no PHP advisory recommends that, and it carries a large performance cost.

Sucuri. Sucuri's 21 October post says its existing rules "were already blocking some of the malicious request patterns," and that it "added more refined virtual patching rules" across the Sucuri WAF network.

Barracuda. Barracuda's post, updated 23 October, says protections for the session upload progress path are "automatically applied to all Barracuda WAF-as-a-Service applications," while appliance users "will have to apply a policy to stay protected."

Google Cloud Armor and Azure WAF

Google Cloud Armor. Google's PHP2Shell post says "Customers with active managed rules do not need to take action; protection against these vulnerabilities is applied automatically." It also tells customers to "enable the File Upload and RFI categories." Cloud Armor covers "applications and services that use global or regional application load balancers."

Azure. Microsoft's Azure network security post lists Front Door rule 99006001 in the MS-ThreatIntel-Response-CVEs group with "Default state: disabled. Customers need to enable the rule." The rule does not block requests. Microsoft says it "removes the potentially malicious elements from the response," and that it "does not generate WAF log entries or hit counts," so you will not see it working in your logs. Application Gateway has an interim header rewrite for now; Application Gateway for Containers has custom rules only.

Cloud-specific patching, including Elastic Beanstalk, App Engine and App Service, is in our guide to PHP2Shell on AWS, Google Cloud and Azure.

Akamai, F5 and Imunify360: What Is Still Unclear

• Akamai: no first-party PHP2Shell statement found as of 23 October 2026. Wiz lists Akamai among partners that prepared "detections and out-of-the-box mitigations," but we have no Akamai rule names or defaults to report. Ask your Akamai account team.
• F5: F5 has a knowledge article, K000163821, that was not publicly readable. Check it on myF5. F5 BIG-IP products also appear on the NCSC-NL list of products that embed PHP; see our guide to PHP2Shell in appliances.
• Imunify360: CloudLinux describes its Imunify360 rules as "a virtual patch" and said, as of its last update, "No rule blocks the out-of-memory path of CVE-2026-109618 yet." With the Imunify360 WAF disabled there is "No coverage from these rulesets."

A note on plugins: WordPress security plugins run inside PHP. PHP's advisory says one confirmed attack path runs "entirely before any application-specific code begins execution," so a plugin firewall is not a substitute for an edge WAF or a patch. Our overview of WordPress security plugins explains what they can and cannot do.

The Origin Bypass Problem

A cloud WAF sits in front of your server as a reverse proxy. If your server also answers requests sent straight to its IP address, an attacker can skip the WAF. Sucuri spells it out: "If attackers can connect directly to your origin server, they may bypass the virtual patching rules and send exploit traffic directly to PHP." Its checklist includes restricting "Direct IPv4 and IPv6 access to the origin" and protecting "Staging, development, test, and backup environments."

This applies to every proxy WAF on this page. Lock your server so it accepts web traffic only from your WAF provider, and check every hostname, including old subdomains and staging sites.

How to Check Your WAF Is Actually Protecting You

1. Confirm the PHP2Shell rule or ruleset is present and enabled (essential for Fastly and Azure Front Door, where it is off by default).
2. Confirm the action is Block, not Log, Count or Monitor.
3. Confirm the rule group version is current (AWS WAF: 2.5 as of 22 October).
4. Confirm every PHP hostname actually routes through the WAF.
5. Confirm the origin refuses direct traffic from outside the WAF.
6. Look at your WAF's event log for PHP2Shell rule hits since 17 October, the earliest attempt date AWS reported. Hits show attempts, not compromises.
7. Patch PHP anyway, restart every worker, and verify the version that serves your pages.

Our website security checklist covers the wider basics once the emergency is over.

Conclusion

As of 23 October 2026, most major WAF vendors have shipped PHP2Shell rules, but the defaults differ: Cloudflare, AWS WAF (at the default version), Imperva Cloud WAF, Sucuri, Google Cloud Armor and Vercel are on without action; Fastly and Azure Front Door need you to switch them on; Imperva's self-managed products and Barracuda appliances need updates or a policy. Check yours, make sure it blocks, close the origin, and then patch PHP to a fixed version, because a WAF is a layer, not a fix. If you need help doing both quickly, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions