On this page
- Who patches my site on shared or managed hosting?
- What exact question do I send my host?
- Email template to copy
- What does each answer from the host mean?
- Which hosts have said what? (checked 22 October 2026)
- Why is "we are on 8.3" not an answer?
- Am I affected? A three-state self-test
- Was my site hit before the host patched?
On shared hosting your provider patches PHP, not you. Ask the host, in writing, whether the PHP serving your domain has the fixes for CVE-2026-109618 and CVE-2026-109619 and whether its workers were restarted. A named patched build plus a restart confirmation is the only answer that settles it. A version number or silence leaves you at unknown.
| Fact | Detail | Source |
|---|---|---|
| Bugs | CVE-2026-109618 and CVE-2026-109619, remote code execution in PHP core, CVSS v4 9.2 | PHP notice |
| Disclosed | 21 October 2026 | PHP notice |
| Fixed upstream releases | 8.5.12, 8.4.27, 8.3.36, 8.2.35. Older branches rely on vendor backports | PHP notice |
| Scope | Every PHP installation that serves web requests | PHP notice |
| Who patches shared hosting | The host. Customers on a VPS or dedicated server patch their own | Host pages below |
| Host statuses checked | 22 October 2026 | This page |
Who patches my site on shared or managed hosting?
On shared and managed WordPress plans the PHP engine is part of the server, and the host controls it. You cannot update it from your dashboard. The control panel PHP selector only chooses which of the host's installed PHP branches your site uses.
A VPS or dedicated server is different. At our 22 October check, Namecheap and OVHcloud both said VPS and dedicated or bare-metal customers manage their own PHP, and the same applies at most hosts. If you rent a server, see who owns patching on a rented server and how to patch the PHP runtime.
What exact question do I send my host?
Send this, for your own domain, and keep the reply. It asks for the two pieces of evidence that matter, a patched build and a restart:
For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP-FPM, CGI or Apache workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.
Email template to copy
Subject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619): written confirmation for [your domain]
Hello,
I host [your domain] with you (account or plan: [plan name or customer ID]).
My control panel shows PHP [version shown in your panel].
Please answer these four questions in writing:
1. Is the PHP runtime that serves web requests for [your domain] patched for
CVE-2026-109618 and CVE-2026-109619?
2. What is the fixed package, build or backport identifier (not only the
branch number)?
3. At what date and time were all PHP workers serving my site restarted or
replaced after the fix was installed?
4. Do I need to redeploy, change a setting, or move to a different PHP
version on my side?
If my server is still waiting for the update, please tell me when it is
expected. I will keep your reply for my records.
Thank you,
[your name]
What does each answer from the host mean?
Match the reply you got to one row. Only the first row moves you out of unknown.
| What the host says | What it means | Your state | Next step |
|---|---|---|---|
| Names the patched package or build, and confirms the workers were restarted | The two things that matter are both stated | Confirmed by owner evidence | File the reply with its date. Then look for signs of earlier compromise |
| "We are on PHP 8.3" or "your panel shows 8.3" | A branch number, not a build. A backport keeps an old number, and an unpatched 8.3 shows the same label | Unknown | Ask again for the build name and restart time |
| "The fix is applied" with no build and no restart time | A claim without evidence | Unknown | Reply asking for the two missing items |
| "You are not affected" | A statement, not evidence. The PHP notice says all web-serving installations are in scope | Unknown | Ask which build serves your domain |
| Still rolling out, no date | The server is waiting | Unknown | Ask for a date, and set your own deadline |
| No reply | No evidence | Unknown | Escalate through the account owner or billing channel, and consider moving the site |
Which hosts have said what? (checked 22 October 2026)
This table records each host's own statement and nothing more. Where the host's pages said nothing specific about PHP2Shell at our check, the status is Unknown. Unknown is not a claim that the host is unpatched. Statements are the hosts' own and were not independently verified.
| Host | Status at our 22 October 2026 check | The host's page |
|---|---|---|
| SiteGround | Says mitigations were applied before release and official fixes after it on 21 October; follow-up says no customer action. Confirm if you pinned a PHP version by hand | Incident note |
| Kinsta | Unknown. No dated PHP2Shell status note found | PHP docs |
| WP Engine | Unknown. No dated PHP2Shell status note found | PHP guide |
| Cloudways | Unknown. No dated PHP2Shell notice found | PHP version guide |
| GoDaddy | Unknown. The 20 October article was guidance before the fix, not a deployment confirmation | GoDaddy article |
| Hostinger | Status page says managed hosting upgrades were completed by 22 October 03:34 UTC, including cPanel servers; no customer action stated. Confirm if you are on a VPS or another product | Status page |
| Bluehost | Partial. The 21 October 23:00 ET update said most servers were patched and the rest still updating; no completion statement found | Status note |
| HostGator | Unknown. No dated PHP2Shell notice found | PHP configuration |
| OVHcloud | Partial. Says shared hosting receives an automatic update, with no dated completion found. VPS and bare metal are customer-managed | OVHcloud advisory |
| IONOS | Unknown. No dated PHP2Shell status note found | PHP settings |
| DreamHost | Partial. The 22 October update said fixes were applied across most of the network, with final server groups still in staging and stability checks | Status page |
| Namecheap | Partial. The 22 October 16:00 UTC update said all but shared and reseller servers 71, 105 and 312 were fixed. VPS and dedicated are customer-managed | Status update |
These rows change fast; the wider picture is on the October 2026 security tracker. A statement about a host's fleet does not tell you about your server, so send the email even if your host says no action is needed. Longer write-ups exist for what Bluehost has said, Hostinger's status and how to check, the Namecheap notice, DreamHost's staged rollout and OVHcloud's advisory, and the rest of the host-by-host guides sit on their own pillar page.
Why is "we are on 8.3" not an answer?
Three plain-English reasons.
Backports keep the old number. Some hosts fix the bug by rebuilding their existing PHP package rather than upgrading to a new version, so a patched server can still say 8.1 or 8.3. A scanner that only reads the number can flag a patched server, and can also miss an unpatched one.
The command line and the website can run different PHP. If support or a tutorial asks you to run php -v, that shows the command-line PHP. The PHP that answers web requests for your domain can be a different build. The PHP notice itself warns that a command-line check may not match the web worker.
A fixed package does nothing until the workers restart. The long-running PHP processes keep serving the old code until they are restarted or replaced. That is why the question asks for a restart time, and why PHP-FPM needs a restart after an update has the detail.
Am I affected? A three-state self-test
Where you stand right now
A passive check from outside can only reach the first two states. Only the host's written reply gives you the third.
- Detected Your site serves PHP and the exposed version is below the fixed release for its branch. Send the email above today and ask for the patched build and restart time.
- Unknown Your site serves PHP but hides the version, shows a branch number, or your host has said nothing specific. This is the common case on shared hosting. Get the build name and the restart confirmation from the host.
- Confirmed by owner evidence You hold a written reply naming the patched build for your domain and a restart or replacement time after it. The runtime is patched. Then check whether anything was planted earlier.
No scan, ours included, moves you from "unknown" to "confirmed". A free scan reads what your site serves and can say a version is affected. It cannot see a backport or a restart.
Was my site hit before the host patched?
AWS reported exploit attempts against its honeypots from 17 October, four days before disclosure, and says it is unclear whether those early attempts would have worked on real systems. At our 22 October check we found no primary source naming a confirmed real-world compromise. Patching does not remove anything left behind earlier.
If your host's fix landed after 17 October, look in the file manager (the indicators to check are listed separately) for PHP files you did not upload, scheduled tasks you did not create, and administrator accounts you do not recognise. The 10-minute small business response and the wider list of urgent security tasks cover the rest. The main explainer is PHP2Shell: affected versions and fixes.
Questions people ask
Do I need to take my website offline as a precaution?
The PHP project's remedy is a patched PHP release, not taking sites down, and we found no primary source that tells shared-hosting owners to go offline. Whether to pause a site is a business call. If your host cannot confirm the fix and the site takes payments or logins, a maintenance page until you have an answer is a reasonable choice.
We have a managed plan and new PHP versions are still not applied. How long should we wait?
Give the host a short, dated deadline in your email, such as 24 hours for a written answer. Hosts' own status pages at our 22 October check described rollouts still in progress for some servers, so a delay is not proof of neglect. If the deadline passes, escalate in writing and treat the site as unknown.
Should I change passwords on my sites?
Patching does not remove anything planted before the patch. If your PHP was unpatched and reachable between 17 and 22 October, change admin and hosting passwords after the host confirms the fix, so a new password is not captured by something still running. Also rotate database passwords and API keys that sit in your site's configuration files.
My host support says I am not affected. Can I trust that?
Ask for the same thing in writing: the patched build or backport name and a worker restart time. A chat agent saying the CVEs do not apply is a statement, not evidence. Until you have the build and the restart, your state is unknown.
I am on shared hosting and cannot patch myself. What can I do?
You cannot update the server's PHP, so your job is to get a written answer from the people who can. Send the question below, keep the reply, and check whether you have pinned an older PHP version in your control panel, which a host's fleet-wide update may not cover. Patch your own CMS and plugins too, though that does not close this bug.
Sources
- PHP security notice, 21 October 2026 (php.net)Names both CVEs and the fixed releases. Says every PHP installation serving web requests is in scope.
- GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (php/php-src advisory)
- GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (php/php-src advisory)
- SiteGround: critical PHP vulnerabilities, October 2026Host statement about its own service.
- Hostinger status pageHost statement about its own service.
- Bluehost status announcement 271Host statement about its own service.
- DreamHost status pageHost statement about its own service.
- Namecheap status update, 21 October 2026Host statement about its own service. Lists shared and reseller servers 71, 105 and 312 as the exceptions at the Oct 22 update.
- OVHcloud advisory on the PHP vulnerabilitiesHost statement about its own service.
- GoDaddy: important PHP security update, 20 October 2026Guidance published before the fix. It is not a deployment confirmation.
- Amazon Threat Intelligence: PHP2Shell exploitation attempts seen in MadPot honeypots before disclosure (AWS Security Blog, 21 October 2026)Vendor telemetry. AWS says it is unclear whether the early attempts would have succeeded on real systems.
Facts on this page are dated and point at the primary source next to them. If a vendor status changes after the date shown, the vendor's page wins; tell us at support@run.cloud and we will update it.