In short: WAF instead of an update does not work for PHP2Shell. A web application firewall, that is, a filter in front of the website, inspects requests and can block known attack patterns. The vulnerability itself sits in the PHP interpreter, however, and only disappears with the update and the restart of all PHP processes. A WAF is a sensible additional layer and a bridge for a few days, not the solution.
Why the question is being asked so often right now
In the PHP2Shell week, many operators read what seemed to be good news: according to its own statements, Cloudflare has had protection rules active since 21 October 2026, 03:02 UTC, including for customers on the free plan. Anyone already behind Cloudflare or another WAF understandably wonders whether the update is still urgent.
The honest answer is yes. Cloudflare itself adds a caveat: rules based on request data alone are not sufficient, so the service additionally inspects the server’s response. Cloudflare has also observed changed attack patterns. And the protection only works for traffic that actually passes through Cloudflare. The details on this provider are described in Cloudflare protection rules against PHP2Shell. This page is about the basic trade-off, independent of the provider.
What a WAF sees and what an update changes
A WAF sits in front of the application. It sees every request, compares it with rules and lets it through, blocks it or logs it. It does not know how PHP processes the request internally. The two PHP2Shell vulnerabilities arise exactly there: CVE-2026-109618 in an out-of-memory condition while request data is only partly initialised, and CVE-2026-109619 through internal state that persists after a request in the same worker.
The update corrects this code. After that, the cause is eliminated, regardless of what a request looks like. Anyone who wants to understand at which point in the sequence of a request this happens will find the basics under The request lifecycle in PHP.
WAF instead of update: the honest comparison
| Criterion | Web application firewall | PHP update with restart |
|---|---|---|
| What is fixed? | Nothing, known patterns are intercepted | The cause in the PHP interpreter |
| Protection against new attack variants | Only if rules are adjusted in time | Yes, the vulnerability no longer exists |
| Can it be bypassed? | Yes, e.g. via direct reachability of the origin server | No, provided all PHP processes have been restarted |
| Speed | Often active immediately | Depends on version, access and maintenance window |
| Side effects | False alarms, disrupted forms or uploads | Rare; compatibility tests needed for version jumps |
| Benefit at the next vulnerability | High, if maintained | None, each vulnerability needs its own update |
| Helps with PHP 8.1 and older? | As a transition | Only through backport or migration |
The table shows why both measures belong together. The WAF is fast and broad, but never complete. The update is complete, but only for one specific vulnerability and not always possible immediately.
One point is often overlooked in practice: a WAF changes the behaviour of the website. Strict rules can block legitimate orders, contact forms or file uploads without anyone noticing at once. Anyone who switches a WAF to blocking mode in a crisis should therefore click through the website’s most important workflows once themselves and check the logs of the first days for blocked but legitimate requests.
How to combine both sensibly
- Immediately: Check whether a WAF is present and whether the appropriate rules are active. For Cloudflare on paid plans, set the Managed Ruleset to Block, according to the provider.
- Immediately: Make sure the origin server is reachable only through the WAF, for example by allowing only its address ranges in the firewall. Otherwise the protection comes to nothing.
- Within the next maintenance window: Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or install the confirmed backport from the distribution.
- Right afterwards: Restart all PHP workers and processes and verify that no old process is still running. New files alone are not enough; more on this under After the update: restarting PHP-FPM and all workers.
- Afterwards: Keep the WAF rules, evaluate false alarms and set exceptions selectively instead of switching rules off across the board.
Something similar can be achieved with your own WAF based on ModSecurity and the OWASP Core Rule Set; the basics are described in Using ModSecurity and the OWASP Core Rule Set. A special form is the filtering of upload requests outside genuine upload paths proposed by specialist authors. It is unofficial, can break forms and belongs in production only after testing.
Neither WAF nor update removes malware that was planted beforehand. After the patch, check whether anomalies have occurred since 17 October 2026.
When you do not need a WAF, and when you do not need a service provider
A WAF is not mandatory for every website. A small company website with a host that patches PHP promptly and confirms it is often sufficiently protected without its own WAF if the CMS and plugins are up to date. Anyone who can update their server themselves within a short time also does not need the WAF as a bridge.
It becomes worthwhile for shops, portals and applications with many forms, for legacy systems that cannot be updated immediately, and where several websites are to be protected centrally. You need a service provider for this only if setup, testing and ongoing maintenance are not covered internally.
How does PHP SOS help?
- We check whether your WAF really sits in front of all access routes and whether the origin server is directly reachable.
- We set up or adjust rules and test forms, uploads and interfaces for side effects.
- We install the PHP update, restart all processes and document the status.
- Where the update takes time, we bridge it with WAF and virtual patching and a fixed date for the real patch.
Conclusion
The question “WAF or update” is badly framed. The update closes the vulnerability; the WAF buys time and catches much else. Anyone who relies only on the WAF is relying on rules that attackers can bypass. Anyone who only patches is left without a bridge again at the next vulnerability.
Frequently asked questions
Is a WAF enough protection against PHP2Shell?
No. A WAF inspects traffic and can block known attack patterns. The vulnerability itself sits in the PHP interpreter and remains until PHP is updated and restarted. Cloudflare explicitly stresses that its rules do not replace the update.
Am I automatically protected behind Cloudflare?
Only for traffic that actually passes through Cloudflare. If the origin server is directly reachable from the internet, the protection is bypassed. On paid plans, according to Cloudflare, you should check that the Managed Ruleset is set to Block.
Is a WAF still worthwhile after the update?
Often yes. A WAF can intercept mass scans, known attacks on plugins and abuse of login pages, and buys time at the next vulnerability. It does need maintenance and testing, however, otherwise false alarms disrupt operations.
What is virtual patching?
This means temporarily shielding a vulnerability with rules in front of the application instead of changing the code. It is a bridge until the real update, not a replacement.