On October 21, 2026, the PHP project released an emergency patch for two critical vulnerabilities that have since become known as PHP2Shell. Both vulnerabilities live in the PHP engine itself, not in WordPress, a plugin, or a control panel, and allow unauthenticated remote code execution. Since nearly every web hosting environment runs PHP, this wasn't something that could wait. We acted immediately.
What exactly is PHP2Shell?
PHP2Shell consists of two vulnerabilities, both scoring 9.2 on CVSS v4.0:
- CVE-2026-109618: memory corruption that occurs when PHP runs out of memory while parsing a specially crafted multipart request.
- CVE-2026-109619: a use-after-free vulnerability reachable through PHP's session upload progress functionality.
Both bugs relate to how PHP manages memory during a failed request, and an attacker doesn't need a login or any vulnerable code of their own to exploit them. That makes this different from most WordPress or plugin vulnerabilities: updating your own website doesn't fix this, the PHP engine itself had to be patched.
Imunify360 WAF rules first, the PHP fix second
As soon as the vulnerabilities became known, we didn't wait for the definitive PHP patch to become available. Our web hosting environment runs Imunify360, our security layer with a Web Application Firewall (WAF). CloudLinux published several WAF rulesets that block the known PHP2Shell attack patterns before the patched alt-php packages were even ready. We activated these rulesets the moment they were released, so any exploitation attempts were already being blocked while the actual fix was still in the pipeline. This prevented damage and downtime during the vulnerable window before the real update landed.
Patched fast across our web hosting environment
Right after that, we got to work on the structural fix. On our web hosting, we use CloudLinux with alt-php (also known as PHP Selector), which lets customers choose their own PHP version. CloudLinux released patched packages for all supported alt-php versions within hours, including end-of-life versions that customers still actively use.
An important detail: the fix was backported into the existing packages. That means the PHP version number itself initially stayed the same, while the fix was already included. It was a new package build under the same version number, with the patch documented in the package changelog. We rolled out these patched packages across all PHP versions on our web hosting servers and restarted every PHP process, so no running worker kept using the vulnerable code.
It's worth emphasizing that a WAF like Imunify360 is a valuable first line of defense, but not a replacement for actually updating PHP. That's why we used both: the WAF rules first as immediate protection, followed by the structural PHP update as soon as it became available.
What does this mean for you as a customer?
As a customer of our web hosting, you don't need to do anything yourself. From the moment the vulnerability became known, you were already protected through the WAF rules, and the PHP packages on our servers have since been updated, regardless of which PHP version you've selected in your control panel. Using an older PHP version through the PHP Selector? Those versions are patched too, since CloudLinux backported the fix to all supported branches.
Why this matters
Vulnerabilities like PHP2Shell show how important it is that your hosting provider doesn't just react, but reacts fast and in layers: an immediate virtual patch via the WAF to prevent damage and downtime, followed by the structural fix as soon as it's available. A vulnerability in the PHP engine itself affects every website on a server, regardless of which CMS or framework they use. By working this way, we make sure your website keeps running securely, without you having to notice anything.
Questions?
Have questions about this update or want to know which PHP version you're currently using? Feel free to open a ticket via the client panel, and we'll be happy to help.