Web & e-commerce

PHP2Shell on shared hosting and cPanel: where each host stands

Where GoDaddy, Bluehost, SiteGround, Hostinger, Kinsta and other hosts stand on PHP2Shell, and what cPanel and VPS owners still have to do themselves.

In this article
  1. 01Do I have to do anything on shared hosting?
  2. 02Where does each host stand?
  3. 03What was the October 23 PHP advisory?
  4. 04Does switching PHP versions in cPanel fix it?
  5. 05I’m on a VPS or my own server. What do I do?
  6. 06Who is my host, actually?
  7. 07Need a hand?
  8. 08Common questions

Last checked October 29, 2026, on each host’s own status page or blog. Most hosts finished patching between October 21 and 23. This was our last scheduled check, so if your host is still listed as rolling out, ask it directly whether your server is done.

On shared hosting, you don’t install PHP. Your host does. That’s good news this week, because the fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) has to happen on the server, and on a shared plan the server is your host’s job. Your job is to confirm the work is done.

If you haven’t read the basics yet, start with our plain-English PHP2Shell guide. This page covers where the big hosts stand, the cPanel detail that trips people up, and what changes if you run your own server.

Do I have to do anything on shared hosting?

Usually not, beyond confirming. On shared and managed WordPress plans, the host updates PHP for every site on the server. You should still get a written answer that your site’s PHP version is patched, because “we have protections in place” and “we installed the fix” are different statements, and a few hosts are still finishing.

The exceptions are VPS and dedicated servers, any plan where you have root or WHM access, and sites on old PHP versions that the PHP project no longer fixes. In those cases, someone on your side has to act.

Where does each host stand?

Here’s what each host’s own page said at our last check, on October 29. Most hosts are done. A few are still rolling out patched builds behind temporary protections, meaning firewall rules or configuration changes that reduce risk until the real fix lands.

Done, nothing for you to do

  • WordPress.com, Pressable and WordPress VIP. Automattic says its sites are protected at the infrastructure level.
  • WP Engine. Its October 22 update says every customer site runs fully patched PHP.
  • Flywheel. Patches finished October 21.
  • Pantheon. Patching complete and the incident closed October 22, including vendor patches for PHP 5.6 to 8.1.
  • Kinsta. Rolled out platform-wide, including PHP 7.4, 8.0 and 8.1.
  • DreamHost. Fixed on shared, VPS, dedicated and DreamPress servers. Older PHP is covered through its extended support program.
  • Cloudways. All active servers updated as of October 22.
  • GoDaddy. Managed WordPress, Web Hosting and Windows Hosting are all patched. On Web Hosting the version number may not change, so GoDaddy says to look for a PHP build dated October 21 or later.
  • SiteGround. It says PHP’s official fixes are applied across all SiteGround servers, with no customer action needed. The fixes it lists are for PHP 8.2 and newer. For 7.4 to 8.1 its staff still pointed to protections as of October 27, so if you’re on one of those versions, ask support to confirm.
  • Hostinger. Patched on every plan except VPS, including builds for PHP 5.2 to 8.5.
  • hosting.com (formerly A2 Hosting). Update completed on October 22.
  • IONOS. Patched on every platform IONOS runs.
  • Namecheap shared hosting. Every PHP version is patched. Older versions keep their old version numbers, so the number alone won’t show the fix.
  • InMotion. Patched on Shared, Reseller, WordPress Hosting, Dedicated and UltraStack ONE, and its status page marks the incident fixed. The version number doesn’t change, so a patched PHP 8.3 still shows 8.3.35. On a VPS or a CWP server, ask support to confirm yours.

Still rolling out

  • Bluehost and HostGator. Most platforms are patched and managed hosting needs no action, but the rollout isn’t marked complete. Their last status update was October 23.
  • Liquid Web and Nexcess. Still deploying as of October 29. If you run your own server with them, check your PHP build and run a package update from the control panel if it isn’t patched.
  • Network Solutions. Its October 23 status update says patched builds are rolling out behind temporary protections and managed customers don’t need to do anything. Its help page still doesn’t say the work is finished, so confirm with support.

You patch it yourself

  • DigitalOcean Droplets, plus VPS and dedicated plans at GoDaddy, Hostinger, Namecheap, IONOS and Network Solutions. Update PHP and restart it. GoDaddy VPS customers update through EasyApache 4 in WHM. On DigitalOcean’s App Platform and Functions, PHP is patched, but you need to redeploy.

Two notes worth knowing. GoDaddy urges anyone on PHP 7.4 to 8.1 to move to 8.2 or later, and DigitalOcean says plainly that no official patch exists for PHP 8.1 or earlier, though its App Platform now builds a fixed PHP 8.1.34 when you rebuild. Upgrading is still the long-term fix for old versions, whatever your host has backported.

What was the October 23 PHP advisory?

On October 23, the PHP project posted a smaller, separate advisory about session upload progress (CVE-2026-115560). It only affects sites with an unusual session setup, and the PHP project calls that setup unlikely in practice. As of October 29 there’s still no fix. It’s coming in the next regular PHP release, and until then the PHP project suggests turning session upload progress off.

On shared hosting, that setting is your host’s call, and several hosts, including Flywheel, Bluehost and HostGator, say their existing protections cover it. If you run your own server, set session.upload_progress.enabled=0 in php.ini or your PHP-FPM pool, then restart PHP. Setting it from inside your site’s code doesn’t count.

Does switching PHP versions in cPanel fix it?

Not on its own. cPanel’s MultiPHP Manager only lets you choose among PHP builds already installed on the server. The fix arrives when the server’s administrator installs the patched packages. On shared hosting, that’s your host. On a VPS where you hold the WHM login, that’s you.

cPanel shipped those packages on October 21 in EasyApache 4 release 25.91: ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36 and ea-php82 8.2.35, plus backported fixes for ea-php81, ea-php80 and ea-php74. If you run WHM, update EasyApache 4 packages, then restart Apache and PHP-FPM. Running PHP workers hold the old code until they restart.

Three cPanel details catch people out:

  • The version is set per domain. If you host several sites on one account, check each one in MultiPHP Manager.
  • The version number can mislead. Hosts running CloudLinux packages may show a patched PHP 8.4 as 8.4.26, because the fix was backported without changing the version. Ask the host rather than trusting the number.
  • cPanel patched its own PHP separately. The cPanel and WHM updates released the same week fix the PHP that runs cPanel’s interface. That isn’t the PHP your website uses.

Moving a site from 7.4 to 8.3 in MultiPHP is still a good idea, since 8.3 gets security fixes through 2027. Just test first, because old plugins sometimes break on newer PHP. Our guide for sites on old PHP covers how.

I’m on a VPS or my own server. What do I do?

Update PHP from the same place you installed it, then restart every PHP process. Ubuntu, Debian and AlmaLinux all shipped fixed packages on October 21. If you run PHP in Docker, pull the updated official image, rebuild and recreate your containers. Restarting an old container doesn’t help.

If your site sits behind Cloudflare, its firewall rules for these flaws are on for every plan. Cloudflare’s own documentation says its managed rules only protect traffic that passes through Cloudflare, and it recommends blocking all other traffic at your server. If your server’s address is public, an attacker can go around the firewall.

Who is my host, actually?

This question sounds silly until you’re the one asking it. Plenty of Tampa Bay businesses had a local web shop set up their site years ago on that shop’s reseller account. In that setup, the company on your invoice isn’t the company running the server, and the support line you need is your developer’s.

Check your billing history for a hosting charge. If there’s none, your developer or a reseller is likely paying for it. Your domain’s DNS records also show where the site points, and a free lookup tool will name the network that owns that address.

Need a hand?

If you’d rather hand this off, call us at 813-531-9400. We pick up, and we can start right away: we’ll find out who hosts your site, get the patch confirmed in writing, and update PHP wherever your plan allows it. You can also reach us through emergency support, and if anything looks wrong on the site, our hacked website repair page explains how we clean it up.

Common questions

My host’s page says “mitigations.” Am I safe? Safer, not finished. Temporary protections block known attack patterns while the real fix rolls out. Ask when your server gets the patched PHP build.

Should I move hosts over this? Not in the middle of it. A migration this week adds risk without speeding up the fix. If your host handled this badly, plan the move once things settle.

My host never replied. What now? Escalate by phone, and in the meantime make sure your site’s traffic runs through a firewall service like Cloudflare. If you can’t get an answer and your site is on PHP 8.1 or older, CISA’s advice is to take it offline until it’s patched.

Let's talk

Want this thinking applied to your business?

One call. We'll look at what you have and tell you what we'd do first.

Book a strategy call →