What to Ask Your Web Host About PHP2Shell (Copy-and-Paste Message)

As of 23 October 2026, many large web hosts say they have installed the PHP2Shell fixes on the plans they manage, and some were still rolling them out. The fastest way to know where your own site stands is to ask your host in writing, with specific questions. Below is a message you can copy, what a useful reply looks like, and what to ask next if the reply is vague.

PHP2Shell is the name for two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. The fix lives in the PHP software on the server, not in WordPress, Drupal or Joomla. WordPress.org's own security post says "No WordPress update is required or planned," and that "you should still check for updates from your web host."

A good host reply names your PHP build, says how the fix was confirmed, and says the PHP processes were restarted. A vague reply says "we're secure" and nothing else. You are entitled to the specific version.

Before You Send It: What to Gather

Two minutes of prep makes the reply far more useful.

• Every domain on the account. Include old landing pages, staging copies and microsites. Each one can run a different PHP version.
• Your plan type. Shared, managed WordPress, reseller, VPS or dedicated. On a VPS or any plan with root access, many hosts say PHP is your job. Our guide to PHP2Shell on shared hosting explains the split.
• The PHP version you see today. Check it in WordPress Site Health, your control panel or a temporary phpinfo() page, using the methods in how to check your PHP version. Note it, but don't panic if it looks old. Many patched builds keep the old number.

The Copy-and-Paste Support Message

Send this through your host's ticket system or by email, not live chat, so you get a written answer you can keep. Replace the parts in square brackets.

Subject: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) status for [your domain]

Hello,

I'm asking about the PHP security release of 21 October 2026 for CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. My account is [account name or number], on the [plan name] plan. The sites are: [domain 1], [domain 2], [domain 3].

Please answer each question in writing:
1. On my plan, who installs PHP updates: you or me?
2. Which PHP version and exact build serves each site? Please give the package version, the build date, or the changelog entry that shows the fix for both CVEs.
3. Were the PHP processes serving my sites (PHP-FPM, Apache, LiteSpeed lsphp or similar) restarted after the fixed build was installed? When?
4. If any site runs PHP 8.1 or older, is a backported fixed build installed, or only firewall rules? Which supported PHP versions can I switch to?
5. Is session.upload_progress.enabled set to 0 for my account, as PHP advised on 23 October 2026 for CVE-2026-115560?
6. Is any firewall (WAF) rule for these CVEs active on my sites, and is it in blocking mode?

If there is anything I need to do myself, please tell me exactly what. Thank you.

[Your name]
[Your phone number]

If your host only offers live chat, use this shorter version and ask for a ticket number or transcript:

Short version: "For [your domain]: which PHP build serves it, does it include the fix for CVE-2026-109618 and CVE-2026-109619 (package version or build date, please), and was PHP restarted after the update?"

What a Good Reply Looks Like

A good reply is specific enough that you could check it. A vague reply asks you to trust it. Here is how they compare:

Why the build matters: vendors often backport a fix into the version they already ship, so the number does not change. CloudLinux's fixed ea-php84 build is 8.4.26-2, not 8.4.27. Plesk's fixed PHP 7.4.33, 8.0.30 and 8.1.34 differ from the unfixed ones only by build date. That is why "which version?" is not enough, and "which build?" is the right question. The upstream fixed releases, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, are listed with each vendor's package numbers in PHP2Shell fixed versions.

Follow-Up Questions for Vague Answers

Reply in the same ticket so the history stays together. Pick the line that matches what you got back:

Two more points help here. First, the command-line PHP can differ from the one serving your site. hosting.com warns that "PHP served by the command line can report a different version from the one serving your site," so a reply based on php -v over SSH may describe the wrong PHP. Second, PHP 8.2 is fixed in 8.2.35 but reaches end of life on 31 December 2026. If your host moves you to 8.2, ask when 8.3 or 8.4 will be available.

How Hosts Have Answered in Public

Many hosts posted status updates you can read before you write. These are quoted from the hosts' own pages and dated. They show what a clear answer looks like. The status of any host can change, so check the current page.

Finished, with no customer action on managed plans

• WP Engine's status page, 22 October, 01:19 UTC: "The patches have been applied to your PHP version, and no action is needed from you. Updated PHP versions: 7.4.33.17 8.2.35 8.4.27 8.5.12". It names the exact builds.
• Kinsta's status page, resolved 22 October, 08:26 UTC: "All sites are protected, the PHP security updates have been rolled out across the platform". Earlier, on 21 October, Kinsta told customers on certain PHP versions who wanted the patch immediately that they could "switch to a lower PHP version and then back to your original version." That tip is Kinsta-specific, so don't assume it works elsewhere.
• Pantheon's status page: "No action is required from customers, as all available versions of PHP on Pantheon receive security updates through our LTS vendor." Pantheon listed end-of-life branches back to 5.6 among those being patched, and marked the incident resolved on 22 October.
• DreamHost's status page, 22 October, 11:12 AM PDT: "The official PHP security updates have been applied across the entirety of our network... No intervention is needed on your end." It covers web hosting, managed VPS, DreamPress and dedicated hosting.

Still rolling out on 23 October

• Nexcess's status page, 23 October, 04:33 EDT: "Our Security and Engineering teams continue to assess the remaining hosting environments and verify the deployment of security updates."
• Liquid Web's status page posted the same update at 04:35 EDT. On 21 October it told self-managed cPanel customers they "can patch" PHP 8.2 through 8.5 and the backported 7.4, 8.0 and 8.1 "by performing a cPanel update" and then a yum update.

You patch on self-managed plans

• Bluehost's status announcement says most platforms are up to date, and: "If you manage your own VPS or dedicated server, run a package update through your control panel."

More statements from shared hosts, including GoDaddy, Hostinger, SiteGround and hosting.com, are quoted in our shared-hosting guide, linked above. Hosts not listed may well have posted too. We include only statements we could read first-hand on 23 October 2026.

If the Answer Is "You Manage PHP"

On a VPS, dedicated server or custom container, many hosts will tell you the update is yours. That is a clear answer, not a brush-off. It means you, or whoever manages the server for you, need to do three things:

1. Install the fixed PHP packages from wherever your PHP comes from: your Linux distribution, your control panel (cPanel, Plesk, DirectAdmin) or a container image you rebuild.
2. Restart every PHP process. The commands for PHP-FPM, Apache, LiteSpeed, FrankenPHP, Docker and the panels are in our guide to restarting PHP workers after a security update.
3. Confirm the fix through a package changelog or build date, not only the version number.

If you don't have someone to do this, our patching team, linked in the conclusion below, can patch, restart and verify for you.

When to Escalate

Most hosts are busy this week, and a first reply may be a template. That's normal. Escalate when a follow-up still doesn't answer the build and restart questions.

1. Follow up once, in the same ticket, with the specific question from the table above.
2. Ask for escalation to the systems or security team. Ask politely: "Please escalate this to the team that manages PHP on my server so they can confirm the build."
3. Use the measures you control while you wait. A WAF such as a CDN firewall can reduce exposure, and some settings help. Our guide to PHP2Shell interim mitigations explains which ones work and what each can break. None of them replaces the update.
4. For sites on PHP 8.1 or older with no confirmed fix, weigh taking the site offline. 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." If you do, Beazley Security advises a maintenance page or network restriction "rather than disabling the PHP handler, which can expose application source code and credentials."
5. If you see signs of trouble, such as unknown files, new admin users or odd redirects, switch from asking about patches to checking for compromise. Start with how to tell if PHP2Shell hit your site.

When to Consider Moving Hosts

Moving hosts is a big job, and doing it in a hurry adds risk. For most sites, the right move this week is to get a clear answer and patch. Moving makes sense to think about when, after an escalation, any of these are still true:

• The host cannot tell you which PHP build serves your site, or how the fix was confirmed.
• Your plan only offers end-of-life PHP (8.1 or older), with no backported build and no date for a supported version.
• You are told PHP is your responsibility, but you have no one to manage it. In that case, a managed plan may be a better fit than a new unmanaged one.
• You need written answers for clients, a board or an insurer, and the host cannot provide them.

If you do move, take a full backup first, test on the new host before you switch DNS, and pick a plan where the host manages PHP and posts dated security updates. Our complete guide to managed WordPress hosting covers what to look for. The split of duties on each plan type is explained in the shared responsibility model for websites.

Keep the Written Record

Save the ticket, the host's reply and the date. If a client, a manager or an insurer later asks what you did about PHP2Shell, a dated reply that names the build is your record. If your site was on an end-of-life version, also note when you moved it to a supported one. This is practical housekeeping, not legal advice. If you have breach-notification or contract duties, ask your lawyer what records you need.

Conclusion

A short, specific ticket is the most reliable PHP2Shell check most site owners have. Ask who patches PHP on your plan, which build serves each site, whether PHP was restarted, what happens to any end-of-life version, and whether upload progress is off. Keep the reply. If the answer is "you manage it," or you'd like a second check across all your sites, our emergency PHP patching team can take it from there. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions