PHP powers roughly 70% of websites. When vulnerabilities like PHP2Shell emerge, virtual patching gives teams a fast way to block known exploit requests at the edge and a protection layer they can keep using as new vulnerabilities appear.
PHP2Shell is the name given to two critical vulnerabilities in PHP’s core, tracked as CVE-2026-109618 and CVE-2026-109619. Because the flaws are in PHP itself, exposure is not limited to one CMS or framework.
Wiz Research estimates(*) that PHP powers 70% of websites worldwide, making the potential reach of these vulnerabilities unusually broad.
Updating PHP to a fixed release is essential. But upgrades can take time: teams may need to test compatibility, coordinate a maintenance window, or wait for a hosting provider or vendor to ship an update. For older systems, a supported update may not be immediately available.
If you have a healthy install of CrowdSec WAF already, you’re automatically protected via the automatic rules and scenario updates.
How long until you can actually upgrade?
The answer depends on which PHP version you run, and there are three tiers:
| Your PHP version | What’s available | Realistic timeline |
| 8.2, 8.3, 8.4, 8.5 | Full official release (8.2.35, 8.3.36, 8.4.27, 8.5.12) | Package upgrade, today |
| 7.4, 8.0, 8.1 | Minimal source backports(*) from the PHP security team | Build from source, or wait on your distro/LTS vendor |
| 5.4.x – 7.3.x | Nothing from the PHP project | Vendor backport, or a major version upgrade |
W3Techs version data(*) puts 26.9% of PHP sites on PHP 7, 7.7% on PHP 5, and a further 21% of the PHP 8 population on 8.0 or 8.1. Combined, roughly 48% of PHP sites have no full official release to upgrade to, they are waiting on a vendor, a rebuild, or a migration.
Covering you while you patch, or when you can’t patch yet: that’s what virtual patching is for.
Respond quickly with a layer at the edge
Virtual patching adds a WAF rule that identifies a known exploit request and blocks it before it reaches PHP or the vulnerable application. CrowdSec has published virtual patches for both CVEs:
- vpatch-CVE-2026-109618 blocks multipart requests with form fields nested 12 levels or deeper, and multipart bodies with more than 50 file parts — the conditions needed to exhaust PHP’s memory during input parsing.
- vpatch-CVE-2026-109619 matches multipart requests carrying a php_session_upload_progress field, the route used to reach the stale-state bug. It inspects the raw body rather than parsed arguments to catch attempts a multipart parser would otherwise reject.
Both are distributed through CrowdSec’s Hub to protected servers and updated automatically.
This gives teams a way to react quickly when a vulnerability becomes public and peace of mind thanks to the exceptional reaction time of CrowdSec vpatch releases. Depending on the application and the rule’s coverage, it may also support a risk-based decision to keep a service available while a permanent fix is planned and applied. Virtual patching is useful beyond a single incident: it provides an ongoing layer that can be updated as new exploit rules become available.
Virtual patching is not a replacement for updating PHP, and it is not a guarantee against every exploit path. PHP’s security advisory(*) states plainly: “There are no complete mitigations; updating is the only safe choice.” A WAF also only inspects traffic that passes through it — if your origin is reachable directly, lock it down to your proxy. Use the WAF as an additional protection layer, and patch as soon as you can.
Get started with CrowdSec open source WAF
CrowdSec WAF is open source. A basic deployment puts the CrowdSec Security Engine and AppSec component on the host, with a bouncer in Nginx, OpenResty, Apache, HAProxy, Envoy, or Traefik to inspect requests before they reach your PHP application.
Request path: website traffic reaches your webserver/reverse-proxy, where the CrowdSec bouncer forwards it to the AppSec WAF for inspection. Allowed requests continue to the PHP application; requests matching a known exploit pattern are blocked at the edge.
- Install the Security Engine on your Linux host using the Linux installation guide.
- Install a WAF-compatible bouncer for Nginx, OpenResty, Apache, HAProxy, Envoy, or Traefik
- Install the WAF collections and enable AppSec. The virtual patching collection is the key step:
sudo cscli collections install crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules- Then follow the WAF quickstart to enable AppSec and connect the bouncer to it. The vpatch rules are distributed through the CrowdSec Hub and updated automatically.
CrowdSec WAF also supports bot detection as an additional feature. It is enabled separately from the virtual patching collection; see the CrowdSec 1.8 bot-detection overview.
For help with installation and troubleshooting, try the official CrowdSec skill for Claude Code and Codex.
Block the attackers already exploiting PHP2Shell
Virtual patching stops the exploit pattern and is part of our open-source solution. There is also a proactive approach enabled by the knowledge brought by the community and validated by CrowdSec IP Reputation Consensus, allowing you to block the IPs already running the vulnerability.
Our detection network validated nearly 450+ proven PHP2Shell attackers in the first 24 hours of observed exploitation. They are published as a dedicated blocklist, PHP2Shell Attackers — CVE-2026-109618 and CVE-2026-109619, updated as new attackers are confirmed.
This is where our two approaches meet, and they are deliberately different products. Detection is open source: the virtual patching rules shared in this article are free, auditable on GitHub, and yours to run on any host. Proactive blocking is commercial: the curated list of IPs already confirmed to be exploiting PHP2Shell is a paid blocklist. One tells you what the attack looks like; the other tells you who is already launching it.
To get the blocklist on your engines, contact us for access.
