Is Your Web Host Patched for PHP2Shell?

PHP fixed the two PHP2Shell flaws on 21 October 2026.⁠¹ The managed and shared hosts I checked reported fixed builds by 22 October, and VPS and dedicated customers were told to patch themselves.⁠²⁠³⁠⁴ If you run a VPS or dedicated server, check which build you have, and if it isn't a confirmed fixed one, patch and restart today. If you're on shared or managed hosting, get your host's patched build number in writing this week.

The complete PHP2Shell guide covers both flaws in full. This article covers one question: did your host do the work, and how do you check?

Who patches your PHP depends on your plan

Three plan types, three answers. On managed hosting, installing PHP is the provider's job, and the providers listed below reported doing it. On shared hosting the provider patches too, but often waits on a panel or OS vendor. Namecheap says it installed the fixes on its shared servers as soon as CloudLinux released them.⁠² On a VPS or dedicated server, you patch. GoDaddy, Hostinger and Namecheap each said so in their own notices.⁠³⁠⁴⁠²

PHP fixed the flaws in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older get no upstream release, only vendor backports.⁠¹ CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October.⁠⁵ PHP lists interim measures, including turning off session upload progress, and says only an update is a complete solution.⁠¹

The third flaw, CVE-2026-115560, is separate. PHP disclosed it on 23 October. It needs an unusual combination: an application switches session.serialize_handler to php at runtime with ini_set() while session upload progress is still enabled. PHP recommends turning upload progress off until the next regular release.⁠¹

What each host did, and when

Rows marked "mirrored" come from a third-party copy of the provider's status page. Every other row comes from a page the provider published, which I opened. The table records what each provider reported at the stated time. It is not independently verified current status. Times are UTC where the provider gave them.

The managed WordPress providers listed above (Kinsta, Pantheon and Automattic's platforms) reported applying protections without requiring customers to install PHP patches.⁠⁷⁠⁸⁠⁹ That covers those providers, not every managed WordPress host. What WordPress owners need to check lists the checks that stay with the site owner.

Reported Shared hosting trailed because it waited on CloudLinux. Web Hosting Today's timeline says CloudLinux's fixed alt-php packages reached its stable repositories at 00:07 UTC on 22 October, and InMotion's shared servers were still waiting for them on 21 October.⁠¹³

Cloudflare's rules went live at 03:02 UTC on 21 October, before PHP's 14:00 release. Cloudflare still tells customers to patch PHP and keep the WAF on as an extra layer.⁠⁶ What Cloudflare's protection covers has the limits.

A patched server can still report an old version

The fix reaches a server in three steps: PHP publishes it, a vendor packages it, and the host installs it and restarts the workers. Web Hosting Today's summary puts it the same way: only the last step removes the flaw from a running server.⁠¹³

Vendors backported the fix into builds that keep their old numbers. GoDaddy says its Web Hosting builds keep the previous version number.⁠³ Hostinger says some sites show 8.5.11 after the update and asks customers to check for a build date of 21 October or later.⁠⁴ Reported Namecheap says CloudLinux's first emergency packages didn't change version numbers, so some PHP versions looked unpatched while the fix was already in place. CloudLinux later shipped builds with PHP.net's numbers, and Namecheap installed them. PHP 8.2 to 8.5 there now show 8.5.12, 8.4.27, 8.3.36 and 8.2.35, while 5.2 to 8.1 keep their numbers with the fixes applied.⁠² cPanel's backports to 7.4, 8.0 and 8.1 also keep their numbers, and its change log names both CVEs.⁠¹⁰

A version string alone can't clear or condemn a server.

If you can run a check yourself, verify the fix yourself before you trust any number. On arm64 hosts, cPanel advised confirming a fixed version, because some repositories published amd64 builds first. That comes from Web Hosting Today's summary, not cPanel's own post, which I didn't open.⁠¹³ On containers, Render notes that distribution packages may backport fixes while retaining an older upstream version number.⁠¹²

Five questions that get a usable answer

Send these to support and keep the reply.

1. Is PHP patched for both CVE-2026-109618 and CVE-2026-109619?
2. Which package build is installed, and where does your notice or changelog name it?
3. Were PHP workers restarted after the install?
4. What covers my PHP version, if it is 8.1 or older?
5. Did interim measures change uploads or database access on my plan, and do they cover CVE-2026-115560?

A build number, or a changelog entry that names both CVE IDs, is a good answer. "We use a WAF" and "we're monitoring" are not, because Cloudflare itself says to patch PHP with its rules on.⁠⁶ Wordfence's advice, as Web Hosting Today relays it, is to ask the host directly whether PHP is patched for both CVEs and restarted.⁠¹³

Question 5 matters because some hosts disabled features. Web Hosting Today reports that one.com warned its countermeasures could disrupt uploads and direct database access.⁠¹³

Old PHP needs its own question. cPanel's change log shows backports for 7.4, 8.0 and 8.1 and no entry for 7.3 and older.⁠¹⁰ InMotion said those branches may not receive a fix and offers TuxCare's extended support for legacy PHP.⁠¹¹ If your plan runs an end-of-life PHP, read that guide before you accept an answer.

What isn't known yet

I can't see every host's current status. Notices I opened were last edited between 22 and 27 October. I couldn't open Plesk's own notice, so this article makes no claim about Plesk-built PHP. I also didn't verify Hetzner, IONOS or Cloudways from their own pages.

Hosts report no breaches, and that's the hosts speaking. Kinsta says it found no evidence of successful breaches.⁠⁸ Hostinger says it saw no increase in malware infections.⁠⁴ Pantheon says it saw no evidence of compromise on its platform.⁠⁹ Each sells the service it is describing.

CISA's listing documents exploitation somewhere. Web Hosting Today reads CISA's definition as covering attempted exploitation, including code that fails on a system that isn't vulnerable, and notes the listing doesn't say which applied. It also reports that Unit 42 withdrew, on 25 October, a link it had drawn between an agency compromise and PHP2Shell.⁠¹³

How you'd notice it's you

You usually won't. A vulnerable server looks normal. The signal is a missing answer: a host with no dated notice that names a build, or a reply that offers only a version number.

A build date helps only when the provider documents that build as patched. Hostinger documents a 21 October or later build date as the check for its managed hosting.⁠⁴ A host that doesn't publish that rule gives you a date with no meaning. Kinsta warns that the PHP version shown in a dashboard doesn't necessarily say whether a security patch was applied.⁠⁸ An old-looking version is not proof of a hole, and a new-looking date is not proof of a fix.

If you run the server, a public phpinfo() page gives the same data to anyone who finds it. Restrict it or remove it.

Ask your host in writing, then patch what you own

Do today

1. Find your plan type and PHP version in your control panel.
2. Install a fixed PHP build (8.5.12, 8.4.27, 8.3.36, 8.2.35, or your vendor's backport) and restart every PHP worker, if you manage PHP and can't confirm a fixed build.
3. Rebuild your Docker image from a patched base and redeploy, if you run PHP on a platform like Render.
4. Decide on session.upload_progress.enabled=0 for CVE-2026-115560, if you manage PHP. Search your code, plugins and vendor/ for session.upload_progress and PHP_SESSION_UPLOAD_PROGRESS, test uploads in staging, then set it in php.ini, an FPM pool or server configuration and restart every PHP worker. PHP says applications that never switch the serialize handler at runtime can leave the feature on. It also says not to rely on ini_set() or .user.ini.⁠¹
5. Send your host the five questions above.

Do this week

6. Compare the build your host names with its own notice or changelog, not with the version string.
7. Test uploads and direct database access, if your host applied interim measures.
8. Confirm arm64 hosts run a fixed build.
9. Ask what covers PHP 8.1 and older, and plan a move to a supported branch.

Can wait

10. Schedule the move off PHP 8.2 before it reaches end of life on 31 December 2026.⁠¹
11. Re-read your host's notice when PHP ships the CVE-2026-115560 fix, and remove the upload-progress setting only after you've confirmed the fix on your version.