Shared, reseller and managed hosting
How to update PHP on shared hosting when your host manages it
On shared hosting your host installs and patches PHP, and you only choose which installed version your site runs. To deal with PHP2Shell, read the full version your site reports, ask the host in writing to confirm a fixed build is live and restarted, and decide what to do if it is not.
Last reviewed against php.net, the NCSC, CISA and the cPanel and Plesk documentation.
Your situation
Four ways hosts hand you PHP
However much control your plan gives you, the PHP builds on the server belong to the host. Pick the card that matches what you see when you log in.
Your panel has a PHP version menu
You can move each site between the versions the host has installed, for example in cPanel's MultiPHP Manager or on a Plesk domain's PHP page. Picking a version does not patch it.
There is no PHP setting anywhere
Common on managed plans. The host chooses the version and patches it, and your part is to ask, check and keep the answer.
The setting exists but is locked
Hosts can switch cPanel's PHP screen off, restrict a domain's version, or limit which PHP settings a Plesk subscription may change. Only they can lift that.
You resell hosting to your own clients
Your clients will ask you, and you will need to ask the company that runs the server. Send the message below once for the whole server, then pass the answer on.
Who does what
The usual split on a shared plan. Your contract may differ, which is one more reason to ask.
| Task | Host | You |
|---|---|---|
| Installing PHP versions on the server | Yes | No |
| Applying PHP security releases | Yes | No |
| Restarting PHP so the fixed build is loaded | Yes | No |
| Server-wide interim settings while a fix is pending | Yes | No |
| Choosing which installed version each site uses | Sometimes | Often, if the panel allows it |
| Testing your site on a newer PHP branch | No | Yes |
| Deciding whether the site stays online meanwhile | No | Yes |
The two most common panels are explained in detail in the cPanel guide and the Plesk guide.
Step one
Find out which PHP your site really runs
Do this before you contact the host, so you can tell whether their answer matches what your site reports.
-
1. Look in the control panel
cPanel lists each domain's version in MultiPHP Manager; Plesk prints it beside the PHP icon on the domain card. A panel may show only the branch, such as 8.3, which is not enough on its own.
-
2. Read the full number from the site
In WordPress, open Tools, then Site Health, then the Info tab and the Server section. Elsewhere, upload a one-line phpinfo() file, open it in your browser, note the version and delete the file. Plesk users can open View the phpinfo() page from the domain's PHP settings instead. Every method, step by step.
-
3. Compare it with the fixed releases
Use the table below. A number that looks too old is not always unfixed, because vendors can backport the fix, but it is always worth a question.
-
4. Write it down
Record the version, the date and where you read it. Repeat for every site on the account, including addon domains and any staging or old campaign site still online.
| Branch | Fixed for PHP2Shell in |
|---|---|
| PHP 8.5 | 8.5.12, or any newer 8.5 release |
| PHP 8.4 | 8.4.27, or any newer 8.4 release |
| PHP 8.3 | 8.3.36, or any newer 8.3 release |
| PHP 8.2 | 8.2.35, or any newer 8.2 release, until the branch ends on 31 December 2026 |
| PHP 8.1, 8.0, 7.4 | Nothing from the PHP project. Only a vendor's backported build covers these, under an unchanged number |
Releases from the PHP project, 21 October 2026. The vulnerabilities themselves are explained on the PHP2Shell page.
Step two
A message to send your host
Send it through the host's ticket system or support email rather than live chat, so the reply is written down and dated. Fill in the square brackets.
A useful reply includes
- A full version such as 8.3.36, or the name of the package that carries the fix
- A date for the update and confirmation that PHP was restarted afterwards
- For PHP 8.1 or older, a dated plan for moving your site to a supported branch
Ask again if you get
- "We keep PHP up to date" with no version, package or date
- A suggestion that a firewall or security plugin makes the update unnecessary
- No answer at all to the question about PHP 8.1 or older
CISA says a web application firewall may give some protection until a system is patched, and php.net says there are no complete mitigations. Neither replaces the update.
Copy this message
Subject: Confirmation needed: PHP security fixes CVE-2026-109618 and CVE-2026-109619 for [your domain] Hello, I look after [your domain] on account [account name or number]. I am checking our position on the two critical PHP vulnerabilities fixed on 21 October 2026, known as PHP2Shell. Please could you tell me: 1. The full PHP version our site is served by today, and where that build comes from (the PHP project, the control panel vendor or the server's operating system). 2. Whether that build contains the fixes. The PHP project's fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If ours carries the fix under a different number, which package or advisory includes it. 3. When the fixed build was installed, and whether every PHP process serving our site has been restarted since. 4. Which PHP versions we can choose on this account, and which of those are fixed. 5. If any of this is not yet in place: the date it will be, and what you have changed on the server in the meantime. A reply by ticket or email that I can keep on file would help. Thank you, [Your name] [Your role and phone number]
If the answer is not good enough
What to do if your host cannot move you to a fixed version
These steps follow the order of the NCSC's priority actions for this vulnerability: update first, mitigate if you cannot, and consider taking the system offline if neither can happen quickly enough.
- 1. Look for a fixed version you can choose yourself. A new branch can be installed on the server without existing sites being moved to it. If the menu offers a fixed 8.3 or 8.4 while your site sits on 8.1, test the site on it and switch.
- 2. Ask for the interim settings at server level, and a date. The PHP project lists partial measures that reduce the risk, such as turning off session upload progress. They have to be set in the server's PHP configuration and followed by a restart, which on shared hosting only the host can do. The interim settings in full.
- 3. Decide whether the site stays online. If neither a fix nor the interim settings will arrive soon, the NCSC's advice is to consider taking the system offline until it is fully mitigated. CISA goes further for servers that cannot be updated straight away or still run 8.1 or older: take them offline. The risk calculator weighs this for your site.
- 4. Check whether anything already happened. Both CVEs are on CISA's Known Exploited Vulnerabilities catalogue. If your site ran a vulnerable build while public, look for signs of compromise before and after any fix: has your PHP site been compromised?
- 5. Start preparing to move. Take a full backup of files and databases now, while you still have access to everything, whatever you decide about the host.
When to change host
Signs it is time to change host
One slow reply in a busy week is not a reason to move. A pattern of these is.
- They cannot say what you run. A host that cannot name the PHP build serving your site cannot tell you whether it is fixed either.
- The fix was available and not installed. cPanel and Plesk both shipped fixed builds on the day the PHP project published its fixes, so a host using either one that is still unpatched has questions to answer.
- Unsupported PHP with no way forward. If you are kept on PHP 8.1 or older and offered no supported branch to move to, the next flaw will leave you in the same place. PHP 8.2 ends on 31 December 2026, so 8.3 or later is the target.
- No choice and no information. No PHP setting, no security notices and no written answers leaves you unable to meet your own obligations for the site.
Questions to put to a new host
- Which PHP branches it offers today, and how soon after a PHP security release it installs the fix
- How it tells customers about urgent security releases, and whether it publishes what it has done
- Whether you can choose the PHP version per site, and test it on a staging copy first
- Whether it supports the branch your site needs now and the next one you will move to
Before moving, back up everything, set up the site on the new host at a temporary address, and check it on the PHP version you will run there. Only then point the domain at it.
Confirm it worked
After the host says it is done
- Read the number again from the site. Use the same method as before. It should now show a fixed release, or the host should have named the backported package that covers it.
- Check every site on the account. Addon domains, subdomains and staging copies can each run a different version from the main site.
- Keep the host's reply with your records. If a customer, insurer or auditor later asks how you handled PHP2Shell, a dated written answer from the host is your evidence.
- Book the next move. If the fixed build is on PHP 8.2, plan the change to 8.3 or later before 31 December 2026. PHP support dates.
Troubleshooting
When the answers do not add up
The host says the fix is in, but your site still shows the old number
Either the old PHP processes are still running, or your site is on a different version from the one the host patched. Ask them to restart PHP for your account, and check whether your domain inherits its version from a server default.
The panel says one version and the site reports another
On cPanel, a domain set to inherit can take its version from a .htaccess file higher up its directory tree. Trust what the site itself reports, and ask the host to set the version explicitly.
You cannot find any way to read the version
WordPress shows it under Tools, Site Health, Info, Server. Otherwise a one-line phpinfo() file shows it; remove the file as soon as you have the number. If neither is possible, the host's written answer is your evidence.
The site broke after you switched to a newer version
Switch back from the same screen straight away, then update the plugin, theme or code that failed before trying again. Moving within your branch, for example 8.3 to 8.3.36, is far less likely to break anything than changing branch.
The fixed version is in the menu, but your site is not on it
On cPanel, changing the server's default version leaves existing accounts with their own setting where they were, so a fixed branch can arrive while your site stays put. Choose it yourself if the panel allows, after testing, or ask the host to move you.
Run your own server instead? Start from how to update PHP on any server, or go straight to Linux, Windows and IIS or Docker.
Quick answers
Hosted PHP: questions, answered
On shared hosting, who has to fix PHP2Shell: me or my host?
The host fixes PHP itself, because only they can install and restart the builds on the server. You still have jobs: confirm the version your site runs, move it to a fixed version if the panel lets you choose, and decide what to do if the fix is late. The NCSC's guidance applies to you as the owner of the website, not only to the host.
My host says my site is safe but it still shows PHP 8.1. Can that be right?
It can. cPanel and Plesk both backported the fix into their PHP 8.1, 8.0 and 7.4 builds on 21 October 2026, and Ubuntu did the same for the PHP 8.1 in its 22.04 release. In each case the main PHP version number did not move. Ask the host which package carries the fix. Then plan to move anyway: the PHP project has stopped supporting 8.1, and CISA's alert names 8.1 and older as grounds for taking a PHP system offline.
Can I apply the interim settings myself in a .user.ini or php.ini file?
Do not rely on it. The PHP project says to set them in php.ini or the PHP-FPM pool configuration and then restart the PHP workers, and that changing them from inside the application with ini_set() is not enough. On shared hosting those files and the restart belong to the host, so ask them to apply the settings. php.net also says there are no complete mitigations: updating is the only safe choice.
How quickly should my host have patched?
No rule binds a private host, but the signals are clear. The fixes were published on 21 October 2026, both cPanel and Plesk shipped fixed builds the same day, and on 26 October 2026 CISA marked both as known to be exploited, setting US federal agencies a deadline of 29 October 2026. A host that cannot give you a date by now is worth pressing.
Should I take my site offline while I wait for my host?
Only if you cannot get it fixed or protected in time. The NCSC's ladder is to update, then apply the temporary mitigations if you cannot, then consider taking the system offline if neither is possible quickly enough. The risk calculator walks through that decision for your site.
Does a managed WordPress plan change any of this?
Only the controls. Managed plans often hide the PHP setting entirely, which makes the host's written answer more important, not less. WordPress itself never updates PHP: core, plugin and theme updates change WordPress's code, not the runtime beneath it.
Know your exposure
Find every PHP server you run
Patching the server you know about is the easy part. A vulnerability scan finds the forgotten staging site, the old microsite and the appliance with PHP inside, then tells you which ones are still exposed.