In short: With a managed server, the provider takes over part of the security, typically the operating system, PHP packages and standard services. The application, plugins, access credentials and responsibility under data protection law mostly remain with you. After PHP2Shell, you should clarify both in writing: what has the provider done, and what is still up to you?
What "managed" means and what it does not
The term is not protected. One provider may understand it as nothing more than applying operating system updates, while another also looks after web server, PHP, database and backups. Some plans include round-the-clock monitoring, others only a contact person during business hours.
In a situation like PHP2Shell, it becomes clear how precise the service description is. The two vulnerabilities CVE-2026-109618 and CVE-2026-109619 are in PHP itself. Whether your provider maintains PHP as part of its platform or whether PHP counts as "your software" is set out in the contract. Do not rely on the assumption that someone is surely taking care of it.
Managed server security: typical division of tasks
The following table shows a common distribution. It does not replace a look at your contract, but it helps you ask the right questions.
| Area | Mostly with the provider | Mostly with you |
|---|---|---|
| Hardware, network, virtualization | yes | no |
| Operating system updates | yes | no |
| PHP packages from the platform | often | if installed yourself |
| Restart of PHP-FPM and web server | often | for your own services |
| Server-wide PHP configuration | often | for special requests |
| CMS, shop, plugins, custom code | no | yes |
| Admin accounts of the application | no | yes |
| Backups | frequently | checking the restore |
| Assessing and reporting data breaches | no | yes |
| Monitoring for attacks | depending on the plan | depending on the plan |
Unclear fields are the real risk. Wherever you would have to write "depending on the plan" or "often", a rule is missing.
Which questions you should ask now
Send your provider a short, factual request. Ask for a reply in text form so that you can present it later. These points should be included:
- Which PHP versions run on our server, and are they protected against CVE-2026-109618 and CVE-2026-109619?
- Since when has that applied, and were all PHP processes and the web server restarted afterwards?
- Was the fix applied as a backport? If so, which package version proves it?
- Were there any indications of attack attempts or unusual processes on our server?
- Are the web server logs from 20 October 2026 onward being retained, and how do we get them?
A fully worded template is under Asking your host for the patch status. The version number in the customer menu is no proof: with backports it often stays unchanged, for example at 8.2.34.
Even if the provider has patched PHP, your application still needs to be checked. A patch does not remove malware that was planted before the update, and it does not prove that nothing happened.
What stays with you
Your part mainly covers the application. Check CMS, shop and plugins for current releases, remove extensions that are no longer used and review the list of administrators. Watch for new files in upload folders, foreign redirects and unusual scheduled tasks in the application.
Then there is the legal side. If personal data falls into the wrong hands in an incident, your company as the controller is generally subject to the reporting obligation, not the provider. The provider must inform you without undue delay as the processor. The basics are explained in GDPR reporting obligation: 72 hours. This is general information, not legal advice; data protection officers or lawyers assess the individual case.
Another point is often overlooked: software that you or your agency installed yourselves on the managed server, such as an additional PHP version from a third-party source, a container or a utility, usually does not fall under the provider's maintenance. So also ask whether the provider knows what is running beyond the standard setup. And clarify who carries out the investigation if there is a suspicion. Many providers restore the platform but do not investigate whether and which data was affected. Yet that is exactly the answer you need to assess possible reporting obligations.
Improving contracts for the future
Use the situation to put the division of tasks in writing. Rules on security updates including restart, on information about critical vulnerabilities, on the retention and release of logs and on support during incidents make sense. Also ask whether the provider notifies you actively or whether you have to ask yourself.
An unmanaged server of your own is the alternative, but it shifts all the work to you. What that means is described in Securing your own root server and vServer.
How does PHP SOS help?
- We read your service description and draw up a task matrix that makes gaps visible.
- We word the technical questions to your provider and assess its answers.
- We check the application part that lies with you for traces and outdated components.
- What the provider does not cover, we take over on request through a security maintenance contract or complement with security monitoring.
Frequently asked questions
Is everything automatically secured on a managed server?
No. Managed means the provider takes on certain tasks defined in the contract, usually the operating system and standard services. The application, plugins, access credentials and your own software often remain with you.
Where does it say what my provider is responsible for?
In the service description and the contract terms, often also in a document on the division of tasks. For personal data, the data processing agreement is added. If there is no clear rule for security updates, ask in writing.
Do I still have to do anything about PHP2Shell myself despite a managed server?
Yes. Get a confirmation that all PHP versions are patched and the processes have been restarted. Also check your application for traces and clarify whether a reporting obligation exists.
Who reports a data breach if the host was affected?
Reporting to the supervisory authority is generally the duty of the controller, meaning your company. As the processor, the host must inform you without undue delay. Have your data protection officer assess the individual case.