PHP2Shell and Cloudflare: What the Managed Rules Cover

As of 23 October 2026, Cloudflare protects every plan against known PHP2Shell exploit attempts: seven rules in the Free Managed Ruleset, seven in the Managed Ruleset for paid plans, and a new response-side ruleset on all plans. Free customers have nothing to switch on. Pro, Business and Enterprise customers should confirm that their Managed Ruleset is set to Block.

What the rules cover is traffic that actually passes through Cloudflare. They do not patch PHP on your server, and they do nothing for requests that reach your server directly. Cloudflare's own advice is to keep the rules on and update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's patched build.

This guide explains what Cloudflare published, how the rule names changed, how to check your account, and where the gaps are. For other vendors, see our PHP2Shell WAF comparison.

What Cloudflare Published

Cloudflare's PHP2Shell post is dated 21 October 2026, with an update on 23 October. Its main points:

• "Cloudflare has developed and deployed web application firewall (WAF) protections since early October 2026, which were deployed about 9 hours ahead of public disclosure."
• "Starting on October 21 3:02 am UTC, Cloudflare customers using our free or paid WAF were protected by default against php2shell."
• "The protections are available and deployed automatically on all plans with WAF deployed, including Free users."
• "Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation."

Cloudflare also says that "updating website code or a plugin(s) alone does not fix these vulnerabilities," and that "If a hosting provider manages PHP, ask the provider to apply the security update." That matches the PHP project: the flaw is in the PHP runtime, not in WordPress or any other app.

Free and Paid Plans: Which Rules You Have

Each managed ruleset has seven PHP2Shell rules. Their names and IDs, as Cloudflare lists them, are below. You can filter your event log by these IDs.

The Rule Names Changed on 22 October

Cloudflare's WAF changelog shows that the rules went live before they carried CVE names:

Why this matters: if you review your events from 21 October, or a teammate exported them that day, the PHP2Shell blocks will appear under "Generic Rules - Anomalous Execution," not "PHP." Search by rule ID instead of by name, since the IDs did not change.

Response-Side Rules: "Full Transaction Detection"

Cloudflare built a new capability for PHP2Shell that it calls full transaction detection. In its words, it "combines signals from the request and response within the same HTTP transaction," and "A matching full transaction rule can block the origin response before it reaches the requester." Cloudflare says the PHP2Shell protections are the first managed detections to use it.

The ruleset for this, the Cloudflare Managed Response Firewall Default, "has been automatically deployed for customers on all plans, including Free." To confirm it is active, Cloudflare says to visit the Security > Security Rules page.

Keep in mind what a response rule means: by the time it acts, the request has already reached your server and PHP has already handled it. It can stop a response leaving, but it does not protect the server itself. That is one more reason patching comes first.

CVE-2026-115560 and the Upload Progress Field Name

On 23 October, PHP published an informational advisory for a related issue, CVE-2026-115560, in the session upload progress feature. Cloudflare says it "affects fully patched PHP releases, including 8.5.12, and will be fixed in PHP's next regular release."

Cloudflare's coverage has a condition: "All Cloudflare WAF customers are protected against known exploit attempts if their site uses PHP's default upload progress field name. Customers who have changed session.upload_progress.name are not covered by the WAF rule." Most sites never change that setting, but some apps do.

PHP's own advice is to set session.upload_progress.enabled=0 until its next regular release, unless you need the feature. That works whatever field name you use. Set it in php.ini or the PHP-FPM pool, then restart PHP. Our interim mitigations guide explains where the setting must go.

How to Check Your Cloudflare Account

1. Check that your hostnames are proxied. In DNS, each A, AAAA or CNAME record that serves your site should show Proxied (the orange cloud). Cloudflare's proxy status docs say a proxied record is what lets Cloudflare "Apply your Cloudflare product configurations (such as WAF rules...)."
2. Paid plans: confirm Block mode. Open your Managed Ruleset deployment and confirm it is deployed and the PHP2Shell rules are not set to log only.
3. Confirm the response rules. Go to Security > Security Rules and check that the Cloudflare Managed Response Firewall Default is active.
4. Review events. Cloudflare says to "visit Security > Security Analytics > Events. Filter by the rule IDs in the table above and inspect the matched request, action, and path." Hits mean someone tried. They don't mean an attack succeeded.
5. Don't narrow the rules too far. Cloudflare lets you scope the Managed Ruleset "to the parts of an application where it is relevant." PHP2Shell is not tied to particular pages. PHP's advisory says one confirmed attack path runs "entirely before any application-specific code begins execution," so leave the PHP2Shell rules on for every PHP hostname.
6. Patch PHP and restart it. Then confirm the version your site actually runs with our guide on how to check your PHP version.

What Cloudflare's Rules Do Not Cover

• DNS-only records. Cloudflare says a DNS-only record "will be answered with the actual origin IP address... This exposes your origin IP address to anyone who queries the record." Traffic to that hostname skips the WAF.
• Direct requests to your server. If your server answers requests sent straight to its IP address, an attacker can skip Cloudflare. Old DNS history can still reveal an IP you used before moving to Cloudflare.
• Staging, dev and old subdomains that run PHP but were never added to Cloudflare or are set to DNS-only.
• Sites that renamed the upload progress field, for CVE-2026-115560.
• New variants Cloudflare has not yet written rules for. Cloudflare says it will "update the rules when and if new techniques and variations emerge."
• PHP that isn't a website, such as admin panels on private networks, cron jobs and internal tools.

Lock Your Origin to Cloudflare

Closing the direct route makes the WAF much more useful. Cloudflare's guide to protecting your origin server lists several options, each available on all plans:

Cloudflare also suggests rotating your origin IPs after onboarding, because "Historical records are kept and would contain IP addresses prior to joining Cloudflare." On shared or managed hosting, ask your host which of these it supports. Our website security checklist covers the other basics worth doing at the same time.

Conclusion

As of 23 October 2026, Cloudflare's PHP2Shell rules are on for every plan, renamed with CVE IDs since 22 October, and backed by new response-side rules. Confirm Block mode on paid plans, make sure every PHP hostname is proxied, close direct access to your server, and filter events by rule ID. Then do the real fix: update PHP and restart every worker. If you think something got through before you patched, start with our website incident response plan, and if you'd like hands-on help, our emergency PHP patching team can handle the update and the checks. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions