In short: With a PHP vulnerability like PHP2Shell, the host is responsible for the PHP update in web hosting, not you. Your job is to get a written confirmation, choose a supported PHP version in the customer menu and check your website for traces of an attack. A patch by the host does not remove malware that reached your website beforehand.
The situation in plain words
PHP is the programming language that most websites, shops and CMS such as WordPress run on. PHP2Shell refers to two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619). Through them, attackers can run their own code on the server without a password. The BSI (German Federal Office for Information Security) has declared warning level 3 (orange) and recommends an immediate update.
With shared hosting, many customers share one server. The technology underneath, meaning the operating system, web server and PHP, is run by the host. You only manage your website, database and access credentials. That is why you cannot apply the PHP update yourself, and you do not have to.
Web hosting and PHP vulnerability: who is responsible?
The split follows from your contract. In most plans, the following rough distribution applies:
| Task | Host | You as the customer |
|---|---|---|
| Update PHP packages | yes | no |
| Restart PHP processes | yes | no |
| Set server-wide interim values | yes | no |
| Choose your website's PHP version | provides | selects |
| Update CMS, plugins, themes | no | yes |
| Credentials and admin accounts | no | yes |
| Check the website for malicious code | partly | yes |
| Data protection assessment | no | yes |
The last row is the important one: if an incident involving personal data occurs on your website, you as the operator are generally responsible, not the host. More on this under GDPR reporting obligation.
What you should do yourself now
1. Get a confirmation. Ask your host in writing whether the PHP versions in your package are protected against both CVEs, since when, and whether all PHP processes have been restarted. You will find a ready-made template under Asking your host for the patch status. Do not be surprised if the customer menu still shows an older version number such as 8.2.34: some providers ship corrections as a backport without the number changing.
2. Check the PHP version. Look in the customer menu to see which PHP version your website uses. PHP 8.1 and older no longer receive official updates from the PHP project. PHP 8.2 reaches the end of support on 31 December 2026. Whether your CMS can handle a newer version, check against the manufacturer's system requirements, for example on wordpress.org.
3. Check the website. Watch for unknown administrator accounts, unexpected redirects, foreign files in the FTP access and warnings in Google Search Console. A list of typical signs is under Am I already compromised?.
4. Create a backup. Download a current backup of files and database and keep it separately. Also ask the host to retain your package's access logs from 20 October 2026 onward.
After the host's confirmation, change the passwords for the customer menu, FTP/SFTP, database and CMS administrators as a precaution, and enable two-factor authentication where possible.
What you cannot solve yourself with shared hosting
The interim measures recommended by php.net, such as session.upload_progress.enabled=0, only work if they are set in the server configuration. According to php.net, an entry in .user.ini or via ini_set() in code is not enough. Memory limits at cgroup level and the restart of the PHP processes are also up to the host.
If your host does not reply or only answers evasively, you have three options: follow up and set a deadline, temporarily put the website into maintenance mode, or move to a provider with a clear statement. The BSI recommends taking web servers off the network temporarily if an update is not possible immediately.
Also check whether your plan is still up to date. Packages that have run unchanged for many years sometimes sit on older server generations with older PHP versions that the host maintains only to a limited extent. Moving to a current plan from the same provider often takes little effort and brings newer PHP versions with it. Ask about it if the answer on the patch status is unsatisfactory.
If the website already looks suspicious
A patch at the host closes the vulnerability for the future. It does not remove a backdoor that attackers installed beforehand, and it does not prove that nothing happened before. If you find anything unusual, do not delete files at random. Preserve the state first so that the cause can still be traced later.
How does PHP SOS help?
- We work with you on the request to the host and assess its reply technically.
- We check your website for web shells, foreign accounts and manipulated files and clean it up if we find anything, through our malware removal.
- In case of acute suspicion, we provide emergency help for hacked websites including evidence preservation.
- We help you choose a suitable PHP version and test the website afterwards.
Frequently asked questions
As a hosting customer, do I have to update PHP myself?
As a rule, no, because with shared hosting PHP is part of the host's platform. You can often choose the PHP version in the customer menu, though. If it shows a version without official updates, you should switch or ask the host how it protects it.
My website is offline. Was I hacked?
Not necessarily. Some providers took websites offline as a precaution to close the vulnerability. Ask the host for the reason and have them confirm whether there are any indications of an attack on your package.
Can I set the interim measures in .user.ini myself?
For session.upload_progress.enabled, php.net explicitly states that .user.ini and ini_set() are not sufficient. The host has to set this setting in the server configuration.
What should I have from the host in writing?
A confirmation that the PHP versions in your package are protected against CVE-2026-109618 and CVE-2026-109619, since when that has applied, and that the PHP processes have been restarted. Keep this reply together with your records.