Cloudflare Free WAF: Security Rules php2shell Vulnerabilities
Cloudflare’s newest PHP2Shell changelog entry is dated Oct 22 and only renamed the rules (detection and Block action unchanged). Free plans have the protection on by default. Official rule IDs · Main PHP2Shell guide
- Free plan = 5 custom rules plus Cloudflare’s own managed rules, which already cover PHP2Shell (CVE-2026-109618 and CVE-2026-109619).
- Check, do not rebuild. Confirm the managed rules are on and watch the events. Add the optional custom rules below only if they fit your site.
- Rules are a stopgap. Cloudflare itself says to update PHP and keep the WAF on as an extra layer.
Cloudflare calls the rules that filter your traffic security rules. In its current dashboard, custom rules are one type of security rule, next to the managed rules Cloudflare maintains for you. This guide explains which ones protect you from PHP2Shell on the Free plan, shows the official rule IDs, adds two small custom rules you can copy, and warns about the mistakes that quietly turn protection off.
Two kinds of rules on the Free plan
| Type | Who writes it | PHP2Shell role | Your job |
|---|---|---|---|
| Managed rules | Cloudflare | Official protection | Make sure they are on. Free plans get them automatically. |
| Custom rules (up to 5 on Free) | You | Extra, optional | Add narrow rules that block things your site never needs. |
| PHP update | Your host | The real fix | Ask for the fixed PHP build and a restart. |
On the Free plan, Cloudflare’s documentation lists a limit of 5 custom rules, and all actions except Log. That means you cannot run a rule in “watch only” mode, so test carefully and keep each rule narrow.
Today’s update (October 23, 2026)
Cloudflare says free and paid WAF customers were protected by default from October 21 at 03:02 UTC, about nine hours before public disclosure.
Source: Cloudflare blog
Two emergency changelog entries renamed the seven Free and seven Managed rules to mention the two CVEs. The rule IDs, detection logic and Block action stayed the same.
Source: WAF changelog
Cloudflare says its analysts will keep updating the rules as new attack variations appear, so check the changelog again before you rely on this post. A fuller breakdown is in the Cloudflare Free WAF setup guide.
Security rules checklist
Step-by-step
- Free plan: the PHP2Shell rules sit in the Cloudflare Managed Free Ruleset and are enabled by default.
- Pro, Business, Enterprise: open your zone’s WAF managed rules and check that the Cloudflare Managed Ruleset is deployed in block mode.
- Your site must be proxied (orange cloud in DNS), or traffic skips every rule.
Menu names have changed over time (“Security → WAF” in older dashboards, “Security rules” in the newer one). Use Cloudflare’s managed rules page if you get lost.
Go to Security → Security Analytics → Events and filter by the rule IDs in the next section. Look at the path, the action and whether a managed or custom rule acted. Blocks show the shield working and that someone is probing you. They do not prove nobody got through.
Official Cloudflare rule IDs
From Cloudflare’s October 21 announcement. The October 22 changelog renamed these to “PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619)” #1 to #7. The full Free and paid tables are in the setup guide.
77454fe2d30c4220b5701f6fdfb893ba
Rule IDs, #1 to #7:
4e315666e8e344cdb64119a3b5ccf32f 00c10e6cc4da4bd08722adeebcd95984 48ddf592361e4fdb97a8a85982dab691 3556683d512a47f2937899c524b1a4c6 da07c85852e34625bb478496302ede46 19373a83abb840e18ab3ce5a7975ce1b 07f0b6ddaabf40b1b2042dade8d613fa
Cloudflare Managed Ruleset ID (Pro, Business, Enterprise):
efb7b8c949ac4650a09736fc376e9aee
Response rule for every plan, in the Managed Response Firewall Default (“Default block for High confidence Signatures”):
afffe22785674c80a31875c848d2242a
Nothing in wp-content/uploads should ever run as PHP. This rule blocks any request for a .php file there. It is a general hardening rule, not a PHP2Shell patch, and it uses up 1 of your 5 free rules.
- Open Security rules (or Security → WAF → Custom rules) and choose Create rule.
- Name it “Block PHP in uploads”, click Edit expression and paste:
(starts_with(http.request.uri.path, "/wp-content/uploads/") and ends_with(http.request.uri.path, ".php"))
- Set the action to Block and deploy.
- Open a few image and media pages to confirm nothing broke.
If the editor reports a syntax error, build the same rule in the visual builder: URI Path starts with /wp-content/uploads/ AND URI Path ends with .php.
Cloudflare’s advisory says restricting unnecessary uploads reduces exposure. Login and cron files never need to receive files, so this narrow rule blocks form-data uploads sent to them. It is an extra layer that Cloudflare and PHP do not list as an official fix.
(http.request.method eq "POST" and any(http.request.headers["content-type"][*] contains "multipart/form-data") and http.request.uri.path in {"/wp-login.php" "/xmlrpc.php" "/wp-cron.php"})- Action: Block. Test by logging in normally afterwards.
- Do not widen it to the whole site unless you are sure you accept no uploads. Media uploads, contact forms with attachments and some plugins send files with this format. If you ever widen it, leave out
/wp-admin/and/wp-json/. - If anything breaks, switch the rule off in the dashboard.
If you copy a rule from another site, note it may be written for different paths and could block your own forms.
A common trick is an “allow my own IP” rule with the Skip action. Cloudflare’s custom rules can skip other security features, and if you skip the managed rules your own browser (or an attacker who shares your IP address, such as on a shared office network) is no longer filtered. Keep allow rules narrow and never skip the managed rules for the whole site.
Ask your host for the fixed build (8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor-patched package), and for a PHP restart. Then keep the WAF on. See the main PHP2Shell guide for the message to send.
What security rules cannot do
The flaw is in the PHP runtime. Only updating PHP closes it.
If your origin server’s IP is reachable directly, attackers can skip Cloudflare. Ask your host to accept web traffic only from Cloudflare where possible.
Cloudflare reports attackers changing payloads. Rules improve after they are seen.
Keep each rule short and specific, and delete rules you no longer need.
Frequently asked questions
Do I need custom rules at all for PHP2Shell?
No. Cloudflare’s managed rules are the official protection and are on by default for Free. Custom rules are optional hardening.
Can I test a rule without blocking?
Not on the Free plan, because the Log action is not offered there. Keep rules narrow, test straight away and turn a rule off if it breaks something.
What if a real visitor gets blocked?
Open the event, note the rule ID and path, then adjust the scope of the rule. For a managed rule, use Cloudflare’s scope settings rather than switching it off.
Is a Page Rule the same thing?
No. Page Rules and Configuration Rules change settings like caching and redirects. Blocking attacks is done by security rules and managed rules.
Does this protect my Blogger blog?
Blogger is not affected, because it runs on Google’s servers. This guide is for self-hosted PHP sites such as WordPress and WooCommerce.
Official sources
Read next: the PHP2Shell protection guide, the cleanup guide if you suspect a break-in, and how to upgrade WordPress to PHP 8.3.
Rule IDs and dates checked on October 23, 2026 against Cloudflare’s blog and WAF changelog. Rule syntax and menus change, so check Cloudflare’s documentation before you deploy. This guide is general information, not a security audit.
Comments