Managed WordPress Hosting vs Shared Hosting: Who Patched PHP2Shell First?

As of 23 October 2026, almost every managed WordPress host and shared host whose PHP2Shell statement we could read says it has installed the fixes on the plans it manages. Two said a staged rollout was still in progress. No independent source ranks hosts by how fast they patched. The times on status pages show when a post went up, not when patching started or finished. So the honest answer to "who patched first?" is that we can't tell you, and nobody else can either.

What we can tell you is what each hosting model does for you. On managed WordPress hosting and on shared hosting, the host patches PHP. The real differences are in how PHP is built, how end-of-life versions were handled and how you confirm the fix. On a VPS or any plan with root access, the patching is yours, whichever company you rent from.

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026, around 14:00 UTC. This page compares hosting models. For step-by-step checks on a shared plan, see PHP2Shell on shared hosting.

Why "Who Patched First" Can't Be Answered Honestly

Lining up status-page times to call a winner doesn't work, for five reasons.

1. A post time is not a patch time. Patching may have started hours before the post, and on a large platform it finishes server by server.
2. Nobody published when their work began. PHP's own advisory says "Linux distributions and LTS vendors received the patches in advance." It does not say which hosts had access before release, and none of the host posts we read say when work started.
3. Scope differs. Pantheon's 21 October post at 19:49 UTC covered its supported versions, 8.2 to 8.5. Its older LTS branches were finished later. WP Engine's first post, at 13:40 UTC, announced mitigations at its CDN, not patched PHP.
4. One company can have several answers. GoDaddy reported its managed WordPress plans patched at 19:30 UTC on 21 October, Windows hosting at 01:20 UTC on 22 October and Web Hosting at 13:30 UTC on 22 October.
5. Time zones and missing times. Some posts give UTC, some Pacific or Eastern time, one gives no time zone at all, and some blog posts show only a "last updated" time.

A table sorted by time would look like a race result. It isn't one, so the table below is in alphabetical order.

What Hosts Posted, With Their Own Times

These statements are from each host's own status page or blog, read on 23 October 2026. Times are converted to UTC only where the host gave a time zone. Status changes quickly, so check the current page. A host missing here may well have posted too. Shared hosts such as Hostinger and hosting.com are quoted in the shared-hosting guide linked above.

The pattern is consistent: customers on managed plans have nothing to do, and the hosts that exclude anyone exclude the same group, VPS, dedicated and root-access customers. More quotes, including what a clear answer looks like, are in what to ask your web host about PHP2Shell.

What Each Hosting Model Does for PHP Patching

Hosting companies often sell several models under one brand, so go by your plan, not the logo. Our guide to WordPress hosting types explains each plan in more detail.

Managed WordPress hosting

Several managed platforms describe rolling out their own PHP builds or images. Pantheon wrote of "updated PHP images," and WP Engine's 7.4 build carries its own number, 7.4.33.17. Our complete guide to managed WordPress hosting covers the model in general.

Shared hosting

On shared hosting, many accounts share a server, and the host installs PHP from its control panel or operating system vendor: cPanel's EasyApache 4, Plesk, CloudLinux or DirectAdmin. The catch is the version number. GoDaddy explains that its Web Hosting uses CloudLinux packages, and "These new builds keep the previous version number." The way to confirm is the build date.

VPS, dedicated and cloud servers

Renting a server from a well-known host does not make it managed. GoDaddy, hosting.com and Bluehost all say self-managed servers are the customer's to update. Google Cloud draws the same line: "Container images you build yourself are your responsibility." If this is you, install the fixed packages, restart every PHP process using our guide to restarting PHP workers after a security update, and confirm the build.

End-of-Life PHP: Where the Models Differed Most

PHP 8.1 and older get no releases from the PHP project, only source backports for 7.4, 8.0 and 8.1 that vendors turn into packages. Hosts handled these versions in different ways:

• LTS vendor builds: Pantheon said all its PHP versions "receive security updates through our LTS vendor," listing branches from 8.1 back to 5.6.
• Own backported builds: WP Engine named 7.4.33.17 among its updated versions. Cloudways said its rollout covered "PHP 5.6 and above."
• Mitigations first, fixes after: DreamHost said sites on PHP 8.1 and older were "protected by the mitigations we deployed early" while fixes under its PHP Extended Support program were built.
• Mitigations, build not stated: A SiteGround staff reply says "server-level security mitigations" cover all versions in Site Tools, "including PHP 7.4." The post does not say whether a 7.4 backport build is installed.
• Panel packages on shared servers: cPanel backported the fix to ea-php74, ea-php80 and ea-php81. Plesk's fixed 7.4.33, 8.0.30 and 8.1.34 differ from unfixed ones only by a build date of 21 October 2026.

If your site runs PHP 8.1 or older, the model matters less than the answer to one question: is a backported build installed, or only mitigations? CISA's 21 October alert says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." Either way, plan a move to 8.3 or newer. PHP 8.2 is fixed in 8.2.35, but it reaches end of life on 31 December 2026.

Firewalls and Mitigations Are Not the Patch

Many hosts added protection in front of PHP. WP Engine deployed CDN mitigations. SiteGround said, "We disabled the affected functionalities on all supported PHP versions." Hostinger switched off session upload progress on its LiteSpeed, PHP Selector and cPanel PHP-FPM setups. These steps lower risk while patching runs.

They don't replace the update. PHP's own advisory says "only an update is a complete solution," and its interim measures "do not make an installation safe." One setting matters after patching too. On 23 October PHP advised keeping session.upload_progress.enabled=0 until its next regular release because of a separate, unlikely issue, CVE-2026-115560. Kinsta and Flywheel both said their existing mitigations already cover it. If your host hasn't said, ask.

How to Verify, Whichever Model You Use

On a managed platform, read the host's status post for your plan and compare any named versions with your dashboard. On shared hosting, check the build date, not just the version: GoDaddy and Hostinger both say a build date of 21 October 2026 or later means the fix is in. On your own server, check the package changelog for both CVE numbers and confirm PHP restarted. Everywhere, check the PHP that serves your pages, because hosting.com warns that "PHP served by the command line can report a different version from the one serving your site." The methods for each panel and CMS are in how to check your PHP version.

Is Managed Hosting More Secure Than Shared Hosting?

For PHP2Shell, both models put the PHP update on the host. The differences are elsewhere. Managed WordPress hosts often take on more of the platform. WP Engine says it blocks public access to files like wp-config.php and debug.log and to "PHP files located within the wp-content/uploads directory." WordPress.com says that while site owners elsewhere typically set up protection with a plugin, "Here at WordPress.com, we handle this on your behalf." Several managed hosts also publish audits. WP Engine lists SOC 2 Type II, SOC 3 and ISO 27001:2022. Kinsta and Pantheon list SOC 2 Type II. Those reports cover the vendor's platform, not your site.

No plan covers what you install and who you let in. Kinsta's responsibilities page says: "You are responsible for installing, updating, and removing any plugins and themes on your WordPress site." Our guide to the shared responsibility model for websites maps who secures what. So "more secure" depends on what you need taken off your plate. If no one on your team will update plugins or watch logins, a managed plan that includes those services may fit better. If someone will, a well-run shared plan can be secure too.

Choosing a Host After PHP2Shell: Questions That Matter More Than Speed

Speed this time doesn't predict speed next time. These questions tell you more:

1. On this exact plan, who installs PHP updates: you or me?
2. Where do you post security updates, and do they carry dates and times?
3. Which PHP versions do you offer, and what do you do when a version reaches end of life? Do you ship backported builds, and from which vendor?
4. How do I confirm a fix myself: version, build date or changelog?
5. Do you restart PHP processes after an update, and will you say so?
6. Is there a firewall in front of my site, and is it in blocking mode by default?
7. What stays my job: plugins, themes, user accounts, backups, custom code?

A host that answers all seven in writing before you buy is showing you how it will act when the next flaw lands. For a PHP2Shell ticket you can send today, use the message in the ask-your-host guide linked above.

Conclusion

No one can honestly say which host patched PHP2Shell first. The published times are post times, the scopes differ and no source ranks them. What the statements do show is consistent: on managed WordPress hosting and shared hosting, the host installed the fix, and on VPS, dedicated and container setups, the work is yours. Confirm the build on a shared plan, read the status post on a managed plan, and on your own server patch, restart and verify. If you run your own servers, or want someone to check every site for you, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions