PHP2Shell: Paying for Managed Hosting, Waiting for the Fix

By late evening on October 21, Cloudways, Kinsta and WP Engine were still reporting rollouts of a critical PHP security fix. On a Liquid Web server, we had already installed it ourselves while the host was still working out its deployment plan.

We spent the day following PHP2Shell across client sites, checking packages and reading hosting updates. On the Cloudways server we could inspect, the old build was still installed that evening. Our access did not let us replace it. The provider controlled when the permanent fix would arrive.

That is an uncomfortable position for a customer paying to have server maintenance handled for them. Managed hosting is partly a promise that someone else will deal with days like this. PHP2Shell showed how much waiting, chasing and hands-on work can remain with the customer.

Hosting comparisons should account for that. Loading times and monthly prices are easy to compare. How a provider handles a critical security release can matter far more than a small difference in either.

The hosting response, in order

The PHP security release fixed two vulnerabilities that could allow an attacker to run code without logging in. This affected the software running WordPress itself, so updating a plugin would not solve it. The PHP team said an update was the only complete solution; temporary configuration changes reduced exposure to particular attack paths.

Here is how seven familiar names in managed and WordPress hosting responded. The table follows the earliest dated notice we could verify for each provider, with its latest patch status alongside it.

Times are UTC on October 21, 2026 unless marked otherwise. Sources checked October 22.

BigScoots had the earliest notice in these records, the night before the release. That earns credit for communication, but an announcement time cannot tell us who finished patching first. None of these records supplied a fleet-wide completion time by our check. Some explicitly described work still underway; others simply did not report when it finished.

Cloudways customers were still waiting that night

Our Cloudways check found PHP 8.4.26 installed, with the package repository offering the same old build. There was no fixed package available through that server’s configured feed. The relevant configuration was provider-owned, so we could not take over the work ourselves.

Cloudways’ public updates tracked a long wait. Its afternoon notice described further interim protections while it prepared a phased rollout of the official patches. At 22:19, that rollout was still in progress.

By then, Cloudways said interim mitigations were deployed across the fleet. That was useful work, and it matters when judging the response. Customers were not being told to wait without any additional protection. But the permanent fix was still being distributed late into the evening, and the server we had checked earlier was dependent on that rollout.

The trade-off became very clear: the same restrictions that let a host control and maintain its platform also prevent a customer’s developer from fixing a delay. Once we had established what was missing, there was little more we could do on that server.

Liquid Web left us doing the update

Our Liquid Web experience raised a different question: who was going to do the work? A package mirror was lagging behind the official cPanel feed. We used the signed official packages to update the server and verified the fixed website and control-panel PHP builds that afternoon.

Later, Liquid Web’s public notice described the route cPanel customers could use to update themselves. Its own deployment plan was still being evaluated. The server we handled was patched, but that result depended on us intervening.

Managed hosting plans cover different things, and we would not expect every product to have identical responsibilities. Even so, emergency security maintenance is a poor time for a customer to discover that their developer needs to take over. If an urgent update requires customer action, the provider should say so clearly and early.

Cloudways was not the only one still rolling out

Kinsta’s notices showed the work progressing through individual PHP branches. It began with validated builds for some versions, then added others through the evening. Its 23:25 update finally listed validated patches rolling out for all the branches in that notice. It had not announced completion.

WP Engine was also still deploying in its 21:52 update. BigScoots had reported a batch rollout at 17:07, with an estimate of a few hours, but its incident record did not yet contain a completion announcement when we checked.

A rushed deployment that breaks customer sites is a failure too. Kinsta’s version-by-version updates showed why testing took time, and they made the remaining work visible. BigScoots described testing its packages before deploying them in batches. Both gave customers more information than a general reassurance would have.

Still, managing that work is part of what the hosting fee pays for. Customers need a realistic account of progress and a clear finish. An estimate that runs out without a follow-up leaves them chasing the answer themselves.

“Protected” left an important question unanswered

Pressable said every PHP version it offered was protected, including sandbox, staging and production sites, and that customers needed to take no action. SiteGround described server-level protections deployed ahead of the release. Neither notice gave us a time at which the PHP patch had finished reaching its customers.

That does not tell us either provider was unpatched. It tells us their public notices could not answer the comparison we were trying to make. Pressable’s statement may have covered completed fixes; it did not spell out that timeline. SiteGround’s article was still talking about the upcoming release when we read it after the release had arrived.

Customers should be able to tell whether a host has blocked known attack paths, started installing the permanent fix, or finished. A short status update can convey that without asking a store owner to understand PHP internals.

Security response belongs in hosting reviews

This incident changed what we want to see in a hosting comparison. A provider can deliver a fast website on an ordinary Tuesday and still leave a customer waiting for a critical fix on Wednesday. That waiting period is part of the service being bought.

Cloudways and Kinsta were still rolling out late in the evening. Liquid Web gave cPanel customers a route to act while its own deployment plan was unresolved. Pressable and SiteGround offered protection statements that did not settle the patch timeline. These are different experiences, even if all the plans can be sold under the broad promise of managed hosting.

A useful hosting review would include the provider’s last serious security incident: how long the permanent fix took, how clearly customers were kept informed, and whether anyone had to hire a developer to finish the job. We would pay more attention to that record than another homepage speed test.