Only check systems you own or are responsible for. This page and our checker work from version numbers you type in. Nothing here tests, probes or scans a server.
Short answer
A WAF (web application firewall, a filter that sits in front of your site and blocks suspicious requests) can lower your risk while you patch, but it is not a fix. Cloudflare, Sucuri and CloudLinux (Imunify360) each added WAF rules aimed at php2shell (CVE-2026-109618 and CVE-2026-109619), and each of them says to patch PHP anyway. The PHP Group’s own advisory says: “There are no complete mitigations, updating is the only safe choice” (php.net).
What each vendor says
Only what the vendors state on their own pages. Each row links to the source.
| Vendor | What it says it did | What it says about patching |
|---|---|---|
| Cloudflare WAF | “Starting on October 21 3:02 am UTC, Cloudflare customers using our free or paid WAF were protected by default against php2shell.” | “Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation.” |
| Sucuri Website Firewall | Deployed “additional Web Application Firewall (WAF) rules” for both CVEs (incident status “Monitoring” at 15:14 UTC on 21 Oct). A Sucuri blog post (21 Oct, 21:12 UTC) adds “more refined virtual patching rules”, and says “WAF protection only works when requests pass through the firewall.” | “WAF protection does not replace patching PHP on your origin server.” |
| Imunify360 (CloudLinux) | WAF rulesets 8.83 to 8.85 (21 Oct) block the known exploit requests and the public exploit tool on Apache, Nginx and Coraza. Since ruleset 8.84, LiteSpeed is covered as well. | “This is an interim mitigation, not a fix.” CloudLinux says fixed alt-php packages are now in its stable repositories (cPanel guide). |
| Wordfence | Published a post-release notice (21 Oct). A follow-up post (22 Oct) says its firewall protects the WordPress application layer only. It announces no firewall rule for these CVEs. | “For these vulnerabilities, updating and restarting PHP is essential.” WordPress automatic updates will not fix them; PHP must be updated by your host or on your own server. |
| Patchstack | Its alert page does not mention a Patchstack virtual patch for this issue (our observation, not a vendor statement). | “Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s patched package.” |
Cloudflare: what to check
- Free plans: Cloudflare says the protection is on by default. It also released a response-side managed rule (“Cloudflare Managed Response Firewall Default”) on all plans including Free, which looks at the origin’s response as well as the request.
- Pro, Business and Enterprise plans: Cloudflare says to “review your Managed Ruleset deployment to confirm it’s deployed block mode” (Cloudflare blog). The blog names the new rules “Generic Rules - Anomalous Execution - 1” to “7”.
- What is not stated: Cloudflare’s WAF changelog says the emergency release “adds four rules to the Cloudflare Managed Ruleset to detect anomalous request patterns” and does not name the CVEs. Its text says four rules while its table lists seven, so we state no rule count. No vendor lists exactly which requests the rules catch, so you cannot know what they miss.
Imunify360: what to check
- Servers with Imunify360 and its WAF enabled receive the rulesets automatically (CloudLinux status).
- ImunifyAV and servers with the WAF disabled get no coverage from these rulesets (CloudLinux blog).
- The newest rulesets are 8.83 to 8.85, and LiteSpeed coverage needs 8.84 or newer. If your server shows an older ruleset, ask your host or server admin to update it, and see the CloudLinux status page for the vendor’s current instructions.
Why a WAF is not a fix
- The bug is in PHP, not in your site. The fix is in PHP itself: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor’s patched package. A WAF only filters requests in front of it; the vulnerable PHP is still installed.
- It only sees traffic that goes through it. A WAF cannot filter requests that never pass through it. If your server’s real IP address answers requests directly, those requests skip the WAF. Restricting the origin to Cloudflare’s published IP ranges is a sensible stopgap, not a cure.
- Rules cover patterns, not the flaw. Cloudflare’s changelog speaks of “anomalous request patterns”. CloudLinux says its Imunify360 rules cover only part of the issue (CloudLinux). We found no vendor statement that its rules cover every request that can reach the flaw.
- Old PHP has no official fix. For PHP 8.1 and older, php.net publishes no release, only minimal source-code backports for people who build PHP themselves. A WAF can help there, but your real fix is a vendor backport or a move to a supported branch (old branches).
Not confirmed: a Wordfence firewall rule for this issue, and any vendor statement that its rules fully cover both CVEs. Check the vendor links above for updates.
What to do now
- Keep the WAF on. Check that your plan’s rules are in block mode (Cloudflare Pro and above) or up to date (Imunify360). Do not turn off other protections.
- Patch PHP. Take a backup or snapshot first, especially if you jump to a new PHP branch. Then use your normal update path:
# Debian / Ubuntu (replace 8.3 with your branch)
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
# RHEL family (check first that your vendor lists a fixed package for your PHP stream)
sudo dnf upgrade 'php*'- Restart PHP. The update does not take effect until you do:
sudo systemctl restart php8.3-fpm # RHEL: php-fpm
sudo systemctl restart apache2 # only if you use mod_php (RHEL: httpd)For Docker, rebuild from a patched base image and recreate the container.
- Verify. Run
php -vand, on Debian or Ubuntu,dpkg -l | grep -E '^ii +php8.3'. Distro packages keep older version numbers because fixes are back-ported, so compare with your vendor’s fixed package version, not the upstream number. Then type your version into the checker and see the fixed versions table. Full walkthrough: php2shell: what it is and how to fix it.
On shared or managed hosting you usually cannot patch PHP yourself. See hosting status for your host’s statement, and ask them directly if there is none. A host’s WAF is the same story: a layer in front, not the update.
Want help with your exact setup?
If you would rather not work out the right steps yourself, we offer a $49 personal patch plan: written steps for your exact setup by email within 24h. Details at /fix-service/.