In short: By its own account, Cloudflare has had protection rules against PHP2Shell active since 21 October 2026, 03:02 UTC, including for customers on the free plan. The rules reduce the risk for traffic that runs through Cloudflare. They do not work if the origin server is directly reachable, and they do not replace the PHP update. Anyone using Cloudflare should check the rule mode, origin protection and patch level.
The trigger: protection before the patch
Cloudflare was unusually early with PHP2Shell. According to the Cloudflare blog, the protection rules were running several hours before the official release of the PHP updates at 14:00 UTC. Cloudflare also reported having observed attack attempts against customers, and that attackers changed their patterns to bypass the rules.
Many operators concluded from this: "We are behind Cloudflare, so we are protected." That is only partly true. This article explains what the rules actually cover. A general weighing of firewall against update is offered by the article WAF or update?.
What Cloudflare rolled out against PHP2Shell
According to the Cloudflare blog, there are three building blocks:
| Plan | Protection according to Cloudflare | What you should do |
|---|---|---|
| Free | new rules in the Managed Free Ruleset, active automatically | check that the domain runs through Cloudflare |
| Pro, Business, Enterprise | matching rules in the Managed Ruleset | make sure the ruleset is set to "Block" |
| all plans | default rule in the new response firewall | do not disable anything, watch events |
The third building block is new. Cloudflare calls it "full transaction detection": the WAF looks not only at the request but also at the server's response. The reason, according to Cloudflare: the request alone is not always enough to distinguish an attack reliably from normal traffic. PHP2Shell is the first use of this feature in the managed rules.
The limits of the Cloudflare rules
As helpful as the rules are, they have clear limits, some of which Cloudflare names itself:
- Only traffic through Cloudflare: The rules check what flows through Cloudflare. If the origin server is directly reachable at its IP address, an attacker can bypass the protection.
- No undoing: According to Cloudflare, a rule on the response side can withhold the response but cannot undo what has already happened on the server.
- Changing attack patterns: Cloudflare adjusts rules continuously because attackers change their requests. There can be a gap between a new variant and a new rule.
- No substitute for the update: Cloudflare expressly recommends updating PHP despite the WAF. Updating application code or plugins does not fix the vulnerabilities either.
- Special case CVE-2026-115560: According to Cloudflare's addition of 23 October, the rule does not apply if the session upload progress name was changed in the configuration. More on this announcement under CVE-2026-115560.
What blocked requests say and what they do not
After the announcement, many customers look at their security events and find blocked requests there. At first, this only shows that your domain was probed and that the rule took effect. A break-in is not established by it. Conversely, an empty event list is not an all-clear: if an attack went directly to the origin server or took place before 21 October, it does not show up at Cloudflare at all.
Reconciling with the logs of the web server itself is more reliable. Requests that arrive there but do not come from Cloudflare addresses point to direct access. Preserve these logs from 20 October onward, as the trade press advises. Cloudflare also points out that restrictions on uploads can reduce the risk but do not replace the PHP update.
The most common weak point behind Cloudflare is not the rule but the way around it: an origin server that responds directly at its IP address or via an unprotected subdomain.
Checklist for Cloudflare customers
You or your service provider can complete these steps at short notice:
- Check plan and rule mode: For paid plans, check in the dashboard that the Managed Ruleset is active in "Block" mode.
- Look at security events: Under Security Events, check whether blocked requests appear. This shows whether your domains were already a target.
- Go through the DNS records: Every record that points to the web server but does not run through Cloudflare is a possible detour. Typical are subdomains for staging, FTP or mail on the same server.
- Seal off the origin: Configure the web server so that it accepts HTTP and HTTPS only from Cloudflare, for example with a firewall using the address ranges published by Cloudflare, or through a tunnel. How this works in general is described in the article Firewall for web servers.
- Test direct access: Check from outside whether the origin responds without Cloudflare.
- Update PHP and restart: The rules are the second line. The first is PHP at a fixed version with a restart of all PHP processes.
For step 5, a harmless test that only requests the headers is enough. The IP address is a placeholder for your origin server:
# Does the origin server respond directly, bypassing Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
If a regular response from your website comes back here, the origin is directly reachable and the Cloudflare protection can be bypassed.
How does PHP SOS help?
- Configuration check: We check the rule mode, DNS records and direct access to the origin server.
- Securing the origin: We restrict the web server to traffic through Cloudflare without interrupting your website.
- Patch and proof: We update PHP, restart all processes and document the status.
- Evaluating events: We review blocked requests and reconcile them with the server logs.
How we combine WAF rules and interim measures is described under WAF and virtual patching.
Conclusion
The Cloudflare rules against PHP2Shell are a real gain, especially because they came early and also on the free plan. But they are a shield in front of the door, not a lock on the door. Anyone sitting behind Cloudflare should make sure of three things: rules in Block mode, no way around the proxy and PHP at a fixed version.
Frequently asked questions
Am I protected against PHP2Shell with the free Cloudflare plan?
According to Cloudflare, free customers also receive the protection rules automatically. However, they only apply to traffic that runs through Cloudflare and do not replace the PHP update on the server. If the origin server is directly reachable, the protection does not take effect.
What do I need to set on paid Cloudflare plans?
Cloudflare advises customers on the Pro, Business and Enterprise plans to check that the Managed Ruleset is running in Block mode. If it is only set to Log, attacks are recorded but not stopped.
What is full transaction detection?
A new Cloudflare WAF feature that looks not only at the request but also at the server's response. This makes it possible to recognise whether an attack attempt is having an effect, and the response can be withheld. According to Cloudflare, it does not undo what has already been executed on the server.
Does Cloudflare also cover CVE-2026-115560?
Cloudflare updated its post on 23 October with CVE-2026-115560. According to Cloudflare, the associated rule does not apply if the session upload progress name was changed in the PHP configuration. Independently of that, php.net recommends setting session.upload_progress.enabled=0.