PHP published fixes for the PHP2Shell vulnerabilities on 21 October 2026. Customers with Imunify360 installed on their managed VPS had already received new firewall rules that blocked the known attack before PHP’s fixes became available. No Layershift customers are known to have been affected.
Key takeaways
- Imunify360 delivered two firewall updates before PHP's fix was due. Our servers with Imunify360 received them automatically, because its firewall is on as standard.
- PHP released fixes only for PHP 8.2 and later. On our servers, older versions were patched with HardenedPHP builds that come with Imunify360.
- Our team installed every fix on every Fully Managed VPS by 23 October. Customers did not need to do anything.
- A firewall reduces exposure while a flaw is open. Patching closes it. You need both.
What was PHP2Shell?
PHP2Shell is the name given to two critical vulnerabilities in PHP, the language behind WordPress, WooCommerce and many other websites: CVE-2026-109618 and CVE-2026-109619. A CVE number is the official reference given to a publicly known security flaw. Both were rated 9.2 out of 10 for severity.
What made the flaws serious is that an attacker could run their own code on a server without logging in. No account or password was needed, so any server using an affected version of PHP to run websites was exposed. A public attack tool was also circulating and being used to scan the internet for vulnerable servers. The risk was real: on 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its list of vulnerabilities exploited in real attacks.
PHP released fixes only for the versions it still supports: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For PHP 7.4, 8.0 and 8.1, it published code patches but no ready-to-install releases, and it offered nothing for older versions. Our PHP2Shell security update covers the technical details.
How Imunify360 blocked the attack automatically
A web application firewall (WAF) inspects requests on their way to your websites and blocks the ones that match known attack patterns, before they reach the vulnerable software.
During PHP2Shell, Imunify360 released two WAF updates on 21 October before PHP's fix was due at 14:00 UTC:
- 09:08 UTC: the first update blocked the publicly circulating attack request. On LiteSpeed servers, this update only logged matching requests and did not block them.
- 13:07 UTC: the second update blocked the public attack tool by recognising its distinctive requests, on every web server, LiteSpeed included.
Three more updates followed by 23 October, all listed in CloudLinux's incident report. Servers with the Imunify360 WAF enabled received every update automatically. On our servers that run Imunify360, the WAF is on as standard, so those customers did not need to do anything.
CloudLinux's advice to Imunify360 users with the WAF switched off was to update PHP and consider enabling it. On our servers, customers never had to make that call.
CloudLinux says IP addresses that scan for or exploit these flaws get a CAPTCHA challenge on servers protected by Imunify360. So an attacker spotted on one protected server is challenged on the others too. It works a bit like a neighbourhood watch.
A firewall has limits, though. As of CloudLinux's last update on 28 October, no Imunify360 rule blocks one way of attacking CVE-2026-109618, which works by making PHP run out of memory, and CloudLinux is clear that only the PHP update closes the flaws.
Why Imunify360 mattered most for older PHP versions
Some applications still run on PHP versions that PHP no longer supports, because they have not yet been updated to work with a newer one. During PHP2Shell, those sites had the fewest options. PHP's own releases stopped at 8.2, its patches for 7.4, 8.0 and 8.1 were source code that has to be built into a working PHP, and older versions got no fix from PHP at all.
On our servers, Imunify360 filled that gap twice over. It comes with HardenedPHP, CloudLinux's patched builds of PHP (shown in Plesk as alt-php), which cover versions back to PHP 5.2. And while our team tested and rolled out those builds on 22 and 23 October, its firewall rules were already blocking the known attack.
Without a solution like Imunify360, an application on an unsupported PHP version is left with no ready-to-install fix from PHP and no firewall blocking the attack while one is found.
What our team did
Applying every fix and patch is part of our managed service: we take that work, and the stress that comes with it, away from customers. On 21 October, we warned affected customers, applied a temporary PHP configuration change and patched Plesk PHP (PHP 8.2 and later). On 22 and 23 October, we tested and rolled out the HardenedPHP builds for older versions, and confirmed with each customer through their own helpdesk ticket once their server was done.
Without a managed team, customers would have had to:
- follow PHP's advisory and check which PHP versions their sites run
- check that the latest firewall rules had reached their server
- find an update for each PHP version, or build PHP from source code patches for PHP 8.1 and older
- test each update and restart PHP without breaking their sites
Our customers did not need to do any of it. Our live status post has the full detail and changelog.
Why you need both layers
A WAF and a patch do different jobs. The WAF blocks known attack requests on the server, before they reach PHP. The patch fixes the underlying flaw, including attack routes no firewall rule covers. Neither layer is enough on its own.
Is Imunify360 on your server?
Imunify360 is included on our Agency Optimised VPS. On a standard Fully Managed VPS, it is a paid add-on.
Already hosting with Layershift? If your server runs Imunify360, it was working for you throughout PHP2Shell: blocking the known attack before PHP's fix was due, challenging attacking IP addresses, and supplying patched builds for older PHP versions. If it does not, your server had our patching but no firewall blocking the attack while fixes were prepared, so add Imunify360 to your VPS. Not sure whether it is installed? Ask our Support team and they will check for you.
Considering Layershift? During PHP2Shell, our engineers handled the customer warnings, the temporary mitigation and every patch. That is part of what fully managed hosting means. Our Fully Managed VPS comes with 24/7 support, and we will migrate your sites for free. Talk to our team to find out more.
Frequently asked questions
Were any Layershift customers affected?
No Layershift customers are known to have been affected by the PHP2Shell vulnerabilities. On our servers running Imunify360, new firewall rules were blocking the known attack before PHP's fix was due, and our team patched every Fully Managed VPS by 23 October, so customers did not need to take any action themselves.
Does Imunify360 replace PHP updates?
No. Imunify360's WAF blocks known attack requests, but it cannot fix the flaw in PHP itself, and as of 28 October, CloudLinux says one way of attacking CVE-2026-109618 is not blocked by any rule. Patching is still essential. On a Fully Managed VPS, we apply PHP security updates for you.
Is Imunify360 included with my VPS?
It is included on Agency Optimised VPS. On a standard Fully Managed VPS, it is a paid add-on, which you can add by contacting us. If you are not sure what your server has, ask our Support team and they will check for you.
How do I check my PHP version is patched in Plesk?
In Plesk, open PHP Settings for your website and click View the phpinfo() page. If the Build Date is 21 October 2026 or later, that PHP version is patched against CVE-2026-109618 and CVE-2026-109619, even if the version number has not changed. Our PHP2Shell security update has the full steps with screenshots.
