Which WordPress host patches automatically? Compared

At our check on 24 October 2026, none of the four managed WordPress hosts we read documents patching everything for you by default. WP Engine and GoDaddy document automatic core security updates, plugin updates are paid or plan-limited, and the PHP runtime is the host's job to patch. Ask your host which layers your plan covers.

Each host's own PHP2Shell status has its own page: Kinsta's patch status, WP Engine, Cloudways and GoDaddy. This page compares what each host says it does the rest of the year. Hosts outside these four, such as Bluehost and HostGator, are covered in the other host guides.

What does "patches automatically" actually mean?

Four different things get called patching. A host can do one and leave the others to you.

Core updates. WordPress installs minor and security releases of core in the background by default, and plugins and themes only in special cases decided by the WordPress security team (WordPress developer docs, modified 14 October 2026). A managed host mostly adds its own testing and schedule on top.

Plugin and theme updates. This is where most WordPress compromises start, and it is usually opt-in or paid, as the table below shows.

Virtual patching. OWASP defines it as a layer that blocks matching exploitation attempts against a known vulnerability without changing the vulnerable code, and adds that it does not remove the underlying vulnerability.

PHP runtime. The package under WordPress. On managed plans the host owns it.

How do Kinsta, WP Engine, Cloudways and GoDaddy compare?

Every cell is the host's own statement, read on 24 October 2026. A statement on a page is a promise about the product, not evidence about your site.

Two cells need a caveat. Where a cell says "not stated", we found no primary page on that point, so ask the host instead of assuming either answer. On GoDaddy, the Patchstack announcement refers to "Managed Hosting for WordPress plans" without tiers, and the firewall help page carries no date.

What does each host do well?

Kinsta is the only one of the four where we found virtual patching described as free. Kinsta says all new environments have it from 9 October and that it began rolling out to existing sites on 14 October 2026. It checks your installed plugins, themes and core version against Patchstack's database. Kinsta also says the feature is not a reason to skip updates.

WP Engine applies core security releases without letting you defer them, and its Smart Plugin Manager runs daily update checks with visual regression testing and automatic rollback. It is included with Managed Hosting Plus, Secure Hosting and eCommerce plans, and purchasable on Shared and Premium. Its Global Edge Security page describes managed WAF rule sets and WordPress-specific rules, and does not say virtual patching.

Cloudways states a shared responsibility model: Cloudways handles OS patching, firmware and the technology stack, and the customer handles application updates. Plugin updating therefore starts at SafeUpdates or your own routine. Its managed Cloudflare firewall is a paid add-on and, per Cloudways, its rules cannot be seen or customised.

GoDaddy updates core in the background and announced Patchstack virtual patching for its Managed Hosting for WordPress plans in April 2026. We could not find the plan tiers, so ask support whether yours is covered.

Does virtual patching fix PHP2Shell?

No host page we read claims it does. The two PHP2Shell flaws are in the PHP engine, below WordPress. The pages above describe virtual patching for core, plugins and themes, and Kinsta's own announcement does not say it covers lower-level PHP flaws. The PHP project's notice says there are no complete mitigations and updating is the only safe choice, and the firewall question has its own page.

That makes the PHP runtime row the one to chase. Three separate facts matter: the fixed build, the worker restart, and your site. The full bug write-up lists the fixed releases. WordPress and plugin updates do not touch the bug, as this explainer shows.

What should I ask my host?

Send this once per site, and keep the reply with its date:

For [your domain and plan], which of these apply to my site: automatic WordPress core security updates, automatic plugin and theme updates, virtual patching against known plugin and theme vulnerabilities, and a managed firewall? For each, is it on by default or a paid add-on, and is it enabled on my site today? Separately, give me the fixed PHP build or backport identifier that serves my site for CVE-2026-109618 and CVE-2026-109619, and the time the PHP workers were restarted or replaced.

• Note which plan and product name you are on, not only the host name
• Ask for each of the four layers by name and get a yes, no or add-on for each
• Ask whether virtual patching is enabled on existing sites or only on new ones (Kinsta's rollout split new and existing sites)
• Ask for the PHP build and restart time separately from the plugin answers
• Turn on plugin auto-updates in WordPress, or buy the host's add-on, if you would otherwise update by hand
• Save every reply with its date

The wider question of who owns each layer is in how patching duties divide up, and the shared hosting question list covers the PHP part.

Am I affected? A three-state self-test

Which host fits which owner?

None of these is a ranking. A host that does less by default can be the right fit if you update on a schedule and can show it.

Does a virtual patch mean nothing got in?

No. A rule blocks requests it recognises, from the day it is active. It says nothing about what arrived before it, and OWASP says the vulnerability remains. If a plugin was outdated while you waited for a rule, look for PHP files you did not upload, new administrator accounts and scheduled tasks you did not create, then work through the hardening steps after a PHP incident. If you want an outside view, the free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup: it can say a version is affected, not whether your setup is exposed.