PHP2Shell Hosting Status: Is Your Host Patched Yet?

What happened on October 21

The PHP project shipped fixes for CVE-2026-109618 and CVE-2026-109619 at about 14:00 UTC on October 21. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Several hosts and Cloudflare had protections live hours before that, because vendors got advance notice.

Every time on this page is as posted on that host's own status page or announcement. Status pages move during the day, and a posted time marks when a host said something, not when the last server was done. Check the source link before you rely on a row.

How fast each host said "patched"

This chart counts hours from the PHP release to each host's first statement that sites were patched. It isn't a ranking of how well the hosts protect you. Several hosts had mitigations running earlier, and "patched" covers different scopes at each one.

Host-by-host status

The table lists what each host has stated publicly. "None" in the last column means the host says it is handling the update for you.

A few notes on specific rows:

• GoDaddy posted three statuses. Managed WordPress at 19:30 UTC on October 21, Windows Hosting later, and Web Hosting still deploying vendor patches at 01:20 UTC on October 22.

• Pantheon reported its 8.1 and older production sites patched at 17:16 PDT on October 21, and all pre-production environments at 19:08 PDT.

• DreamHost said at 10:59 PM PDT on October 21 that the official fixes were deployed, and at 4:24 AM PDT on October 22 that it was running final checks on the remaining server groups.

• Cloudways named PHP 5.6 to 8.4 in its 22:19 UTC patched list. It didn't list 8.5, and old versions are covered through extended-support partners. It called the rollout complete at 10:20 UTC on October 22 and is contacting a small group of customers who need extra help.

• Kinsta marked its status-page incident resolved at 08:26 UTC on October 22: "All sites are protected." It kept its Cloudflare firewall rules in place and said it saw no evidence of breaches tied to the flaw.

• SiteGround published its note at 11:30 UTC, before the fix existed, and doesn't state patch versions. That's a mitigation, not a patched version number.

• Hostinger finished its rollout at 06:44 UTC on October 22. VPS plans are the exception, so the update is yours there.

• Bluehost posted its last update at 23:00 EST on October 21. The notice is titled "PHP Updates" and doesn't name the CVEs, so confirm with support if you're unsure it covers PHP2Shell.

• Namecheap listed the servers still pending at 10:27 UTC on October 22: resellers 48 and 55, and regular servers 71, 72, 86, 105, 165, 310, 312 and 320.

InMotion has a status notice on PHP configuration updates, but we couldn't read its details. We found no public statement from WP Engine. That doesn't mean either has done nothing. Open a ticket and ask them directly, using the questions at the end of the next section.

Key finding

"Mitigated" and "patched" aren't the same state. A mitigation switches off one code path. Only the fixed PHP version closes the flaw.

Who still has to act

Managed WordPress hosting

Pantheon, Cloudways, Kinsta and GoDaddy Managed WordPress all say the work is theirs, and Cloudways and Kinsta now call it done. Your job is to confirm it. Look at the patch level (the next section covers how) and watch the host's status page until it closes the incident. If you manage client sites on a managed plan, save the status-page link in your ticket notes so you can answer a client's question in one reply.

Shared hosting

Shared plans sit in the middle. UnderHost and Hostinger say their shared servers are patched. GoDaddy Web Hosting, Bluehost and a few Namecheap servers were still being fixed at our last check. You can't patch PHP yourself on shared hosting, so check the version your site reports and ask support for a date if it's behind.

VPS and dedicated servers

On a server you control, the host won't touch your PHP. Namecheap's notice says "please update PHP now" for VPS and dedicated plans, and GoDaddy and UnderHost say the same about self-managed servers. First see what you run:

php -v
php -r 'echo PHP_VERSION, "\n";'

The command line version can differ from the one that serves web requests, so use Site Health for the final answer. Then update through your package manager. On Debian or Ubuntu:

sudo apt update
sudo apt upgrade

On RHEL-family systems:

sudo dnf upgrade

On cPanel servers, EasyApache 4 version 25.91 shipped on October 21 with updated ea-php82 to ea-php85 packages and the fix backported to ea-php74, ea-php80 and ea-php81. Liquid Web's guidance for cPanel customers is to run the cPanel update and then a package update:

sudo /scripts/upcp
sudo yum update

Restart PHP-FPM or Apache afterwards so every worker picks up the new binary. If you can't update right away, php.net describes a stopgap: set session.upload_progress.enabled=0 and restart every worker. It says that blocks the confirmed session paths but not other variants, and that only an update is a complete solution.

Cloudflare in front does not replace patching

Cloudflare turned on default WAF protection for free and paid plans at 03:02 UTC on October 21, about 11 hours before disclosure. That's real protection, and Pro, Business and Enterprise customers should confirm their Managed Ruleset is in block mode.

Watch out

A WAF is not a patch. Cloudflare's own advice is that customers should still patch PHP "even with WAF protections". Anything that reaches your origin without passing through the proxy skips the rules.

Questions to put to your host

If your host isn't in the table, or you're not sure, ask these:

• Which PHP versions on my plan have the October 21 fixes, and when did they go live?
• Is my plan patched, or only mitigated?
• What's the plan for PHP 8.1 and older sites?
• Did every PHP-FPM worker restart after the update, so no server is still running the old binary?

How to check your own host

Don't guess from a status page. Ask the server. In your dashboard, go to Tools > Site Health, open the Info tab and expand Server. The PHP version line shows what your site runs.

Compare it with the fixed releases:

If your number is lower, you aren't patched upstream. One catch: some hosts and Linux distributions backport fixes without changing the version string, so a lower number isn't always proof of exposure. Before you panic or open a ticket, check the package changelog.

Lower number? Read the package changelog

The changelog is the one place that says whether the fix is in. On a VPS or dedicated server, run the line that matches your setup as root:

# cPanel and CloudLinux (EasyApache PHP)
rpm -q --changelog ea-php83-php-common | head -5

# AlmaLinux, Rocky or RHEL (distro or Remi PHP)
rpm -q --changelog php-common | head -5

# Ubuntu or Debian
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -m3 109618

Swap 83 or 8.3 for your branch. If the output names CVE-2026-109618 or CVE-2026-109619, you're patched, whatever the version string says.

CloudLinux is a real example. Its EasyApache builds dated October 21 still report PHP 8.3.35 and 8.4.26, below the fixed releases, yet their changelogs list both CVEs. The build to look for ends in 8.3.35-2.cloudlinux.2 or 8.4.26-2.cloudlinux.1. On a managed server your host installs these for you, and the changelog lets you confirm it without waiting on a busy support queue.

One last step on any server you patch yourself: restart PHP. LiteSpeed servers need systemctl restart lsws, and PHP-FPM servers need the FPM service restarted, or the old code keeps running in memory.

PHP 8.1 and older receive no updates from the PHP project. Minimal source backports exist for 7.4, 8.0 and 8.1, and hosts that ship them (Pantheon's long-term support versions, Cloudways through its partners, Liquid Web's 8.1.34-5 build) are covering you in a vendor-specific way. If your host isn't doing that, move to a supported branch. Our guide to changing the PHP version on any host walks through the steps, and the latest PHP version for WordPress explains which branch to pick.

Is anyone being attacked?

The reports disagree, and we're not going to reconcile them.

Qualys said on October 21 that active exploitation attempts targeting PHP2Shell have been observed in the wild, citing reports from Amazon Threat Intelligence, Cloudflare and Patchstack hosting partners. Cloudflare said it observed attack traffic targeting its customers, without giving a time.

Pantheon saw something milder. It blocked more than 60,000 suspicious probing requests and said at 12:30 PDT it had no evidence of widespread exploitation attempts or any successful exploits. DreamHost said at 6:46 AM PDT it hadn't observed any attack traffic. Those statements were made at different times, on different networks, and the picture can change quickly.

Check your site

Not sure what your server announces? Our free scan at wpvanguard.com reports the PHP version your site exposes and flags when it's missing security fixes. If you look after client sites, run it across your whole list today, then use the table above to chase the hosts that haven't finished.

References

• PHP project release archive for 2026
• GoDaddy: important PHP security update
• Pantheon status incident
• DreamHost status incident
• Cloudways status
• Liquid Web status incident
• Namecheap status update
• Kinsta status page
• Hostinger: protections against PHP2Shell
• Bluehost status: PHP Updates
• SiteGround blog post
• UnderHost patch guide
• cPanel EasyApache 4 changelog
• Cloudflare: PHP vulnerabilities and WAF protection
• Qualys: PHP critical security release