PHP2Shell and your WAF or CDN: what the vendor rules cover
Several security vendors had rules in place before PHP2Shell was disclosed. That bought real time on 21 October, and it is easy to mistake it for a fix. This guide sets out what each vendor published, whether you have to do anything to get it, and what each says its rules do not cover.
Three things to check, whatever you use
- Is the rule actually blocking? Some rules arrive on by default, some only if a managed ruleset is deployed, some only after you opt in, and some ship in detect mode.
- Can the origin be reached directly? A rule at the edge protects nothing if the server's own IP address answers requests. Restrict the origin so it accepts traffic only from your WAF or CDN.
- Is the traffic inspected at all? Network signatures cannot see inside encrypted traffic that is not decrypted, and cloud WAFs inspect only the first part of a large request body.
What vendors published
| Vendor | Product and rules | Do you need to act? |
|---|---|---|
| Cloudflare | Seven "Anomalous Execution" rules in the Free Managed Ruleset and seven in the paid Managed Ruleset, deployed from 03:02 UTC on 21 October, plus a response-phase rule that can block a response showing a successful exploit | Free plans: no. Pro, Business and Enterprise: confirm the Managed Ruleset is deployed in block mode |
| Akamai | App and API Protector, Adaptive Security Engine rule 3000991, plus existing command-injection rules | Akamai does not state the default action; check it |
| Imperva | Cloud WAF protection out of the box; Elastic WAF and WAF Gateway after a software update, and for Gateway also a security content update | Cloud WAF: no. Self-managed: update |
| Fastly | Next-Gen WAF virtual patch for both CVEs | Yes: opt in from the WAF dashboard |
| Palo Alto Networks | Threat ID 543004 from 05:21 UTC on 21 October for Advanced Threat Prevention Plus, and IPS signatures 543004 and 97622 to 97625 later that day | Check content updates and the action |
| Check Point | IPS protection CPAI-2026-15172 | Yes: Check Point advises setting critical protections to Prevent, not Detect |
| AWS | Rule PHP2Shell_BODY in version 2.3 of the AWS WAF PHP application managed rule group, now the default version, covers CVE-2026-109619. For CVE-2026-109618 AWS points to the Core rule set's SizeRestrictions_BODY rule, and publishes a guide to custom rules | Web ACLs already using the PHP rule group on its default version get the new rule; otherwise add the rule group or upgrade a pinned version |
| Google Cloud Armor | Protection applied automatically for customers with active managed rules; Google recommends at least the File Upload and RFI categories | Check that managed rules are active |
| Microsoft Azure | Front Door WAF managed rule 99006001, rolling out until 28 October. Application Gateway: a header-rewrite workaround now, a managed rule later | Yes: the Front Door rule is disabled by default and must be enabled |
| Cisco Talos | Snort rules 67359 and 67360, also in the free Community Ruleset | Update your ruleset |
| Corelight | Open-source Zeek package and Suricata rules 3000650 to 3000652 | Install from the published repository |
| CloudLinux Imunify360 | ModSecurity ruleset 8.83 | Arrives automatically with the Imunify360 WAF enabled; on LiteSpeed it logs but does not block |
| Automattic | WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr | Automattic says there is nothing customers need to do |
What the vendors say their rules do not do
Most vendors published caveats with their rules, and they are worth reading as a set, because together they describe why patching is not optional.
- Cloudflare: customers should patch PHP even with WAF protections in place. Its response-phase blocking stops a response leaving, but cannot undo actions already performed at the origin.
- Fastly: assume active mitigation is only partial protection, and that it may require blocking a substantial portion of legitimate traffic.
- CloudLinux: its rule covers one attack path, not both CVEs in full, and a request that differs from the public pattern may not match.
- Check Point: gateway controls reduce risk but do not replace the PHP update, and encrypted traffic that is not inspected bypasses network signatures.
- Cisco Talos: there are no intermediate or temporary controls that provide comprehensive protection.
- AWS: one of the two vulnerabilities is largely outside the reach of any web application firewall, and an edge WAF cannot see the internal structure of a multipart body, PHP worker memory or server configuration.
- Sansec, for its own e-commerce firewall: the vulnerable paths run inside PHP before store code and before its product, so do not wait for a rule.
Using rules well while you patch
- Treat a WAF hit as a reason to look at that server, not as proof it is safe. Cloudflare reported attackers mutating payloads to get around its rules on day one.
- Log matches, not just blocks, so you can see which hosts are being targeted and patch those first.
- Rate-limit large POST requests per client: third-party analysis of a public proof of concept describes hundreds of oversized requests from one address before success.
- Keep the rules after patching. They cost little and catch the stragglers you did not know you had.
Sources
- PHP web runtimes (CVE-2026-109618 and CVE-2026-109619) The PHP2Shell_BODY managed rule and the status of AWS services.
- Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations Front Door managed rule 99006001, disabled by default, and the Application Gateway workaround.
- Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) Which attack elements an edge WAF can and cannot mitigate, and how to deploy rules without breaking uploads.
- Cloudflare deploys protections against php2shell vulnerability Rule sets, defaults, deployment time and the response-phase rule.
- Critical remote code execution vulnerabilities in PHP core Adaptive Security Engine rule 3000991.
- PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment Cloud WAF, Elastic WAF and WAF Gateway coverage.
- Fastly's Proactive Protection for PHP2Shell The virtual patch and its stated limits.
- Critical RCE Vulnerabilities Discovered in Core PHP: CVE-2026-109618 and CVE-2026-109619 Customers must opt in to the virtual patch from the WAF dashboard.
- Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 Threat ID 543004 and the IPS signatures.
- php2shell: What We Know About the Leaked Critical PHP Vulnerabilities IPS protection CPAI-2026-15172 and the limits of gateway controls.
- Two critical RCEs in PHP core Snort rules 67359 and 67360.
- php2shell: Zeek and Suricata Detections for PHP RCE Open-source Zeek and Suricata detections.
- PHP CVE-2026-109618 and CVE-2026-109619: Imunify360 Ruleset 8.83 Blocks the Public Exploit Shape Imunify360 ruleset 8.83 and its coverage limit.
- Your Sites Are Protected Against the PHP2Shell Vulnerabilities Platforms covered without customer action.
- PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) Why an in-application firewall cannot stop these paths.
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 Google Cloud is not itself vulnerable; Cloud Armor managed rules apply protection automatically.
Questions
Related questions
We are behind Cloudflare. Are we protected?
Partly, and only if traffic cannot reach your origin directly. Free plans received the rules by default; paid plans need the Managed Ruleset deployed in block mode. Cloudflare itself tells customers to patch PHP regardless.
Does a WordPress security plugin help?
Not against the demonstrated paths. Plugin firewalls run inside PHP, after the request has been parsed, and those paths run during parsing. Keep the plugin, but update PHP.
Is there an official OWASP Core Rule Set rule?
None had been found at the time of writing. Community ModSecurity rules exist, but they are written against known proof-of-concept shapes and need request body inspection enabled.
Keep reading
More guides
-
Patching PHP2Shell: platform by platform
Where the fixed PHP packages are for Debian, Ubuntu, RHEL and its rebuilds, Fedora, SUSE, Alpine, Amazon Linux, Docker, control panels and managed hosts, and how to make sure the new binary is the one running.
Read the guide -
PHP2Shell on PHP 8.1, 8.0, 7.x and older
There is no official fixed release below PHP 8.2. What the PHP project provided for 7.4, 8.0 and 8.1, where distribution fixes come from, and what to do with anything older.
Read the guide -
PHP2Shell mitigations when you cannot patch yet
The configuration changes the PHP project published for systems that cannot be updated today, what each one blocks, what it breaks, and the two settings that make things worse.
Read the guide