The most common question we have heard since 21 October is not "am I vulnerable?" but "whose job is this?". PHP2Shell cannot be fixed by updating WordPress, a theme or a plugin, because the bugs sit in PHP itself. Whether the fix reaches your site depends on how the site is hosted, and the answer is less obvious than it looks.
Shared hosting (cPanel, Plesk, DirectAdmin)
The host maintains the PHP packages. You choose which version your domain uses.
The provider installs and updates the PHP builds on the server. That part you can leave to them, although it is worth verifying rather than assuming. What the host does not do is change the version your domain is set to. If your account's PHP selector still points at 7.4 or 8.1, the host's patching does not reach you, because no patch exists for those branches. You, or whoever manages the site for you, must switch the selector to a supported branch and check the site afterwards.
Managed WordPress hosting
The host handles the runtime, usually within a day or two. You confirm.
Managed WordPress providers run PHP for you and typically rolled the fix out fleet-wide. They also tend to show the PHP version in the site dashboard, so confirmation is a thirty-second job. The residual risk is a site pinned to an old PHP version at your own request, often because a plugin once broke on PHP 8. If that is your situation, the plugin problem has now become a security problem and needs solving.
Unmanaged VPS or dedicated server
You, entirely.
An unmanaged server comes with an operating system and nothing else. Package updates, PHP restarts, web server configuration and monitoring are yours. If nobody has run the package manager since 21 October, the server is unpatched. The practical minimum is an update of the PHP packages, a restart of PHP-FPM or Apache, and a check of the running version. Unattended security upgrades are worth enabling afterwards.
Managed VPS or server management contract
The provider, within the scope of the contract. Read the contract.
"Managed" ranges from "we monitor uptime" to "we patch everything within 24 hours". Ask whether operating-system security updates are included, whether PHP is covered, and whether service restarts after updates are part of it. A dated confirmation for PHP2Shell is a reasonable thing to request.
Platform hosting (Laravel Cloud, Forge-provisioned servers, Heroku-style platforms, Vercel-style PHP runtimes)
It depends on where the PHP binary lives.
- On a platform that runs the PHP runtime for you, the platform patches it; your job is to check that the deployed application has restarted on the new runtime.
- With a provisioning tool such as Laravel Forge, the server is yours: the tool installs PHP, but ongoing package updates and restarts are your responsibility unless you have enabled automatic updates.
Containers (Docker, Kubernetes)
Whoever owns the image.
Official php images were rebuilt with the fixed releases; images that start from a distribution base and install PHP from packages pick up the vendor's fix on rebuild. Nothing changes in production until the image is rebuilt and the containers are recreated. If an agency built your deployment pipeline, confirm that a rebuild has happened, not just a code deploy.
Agency-built sites
This is where most gaps are.
A site built by an agency two years ago, hosted on an account the client pays for, often has nobody actively responsible for the runtime. The agency assumes the host patches; the host patches its packages but leaves the version selector alone; the client assumes the agency is on it. Every party is partially right and the site stays on PHP 7.4.
If you own such a site, the fastest fix is a single email to the agency and the host with one question each: "Which PHP version does my site run today, and is it one of 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or a package with the backported fix?"
The three gaps, summarised
- Version selectors. Hosts patch branches; they do not change the branch your domain uses.
- Restarts. Packages are installed, processes are not restarted, old code keeps running.
- Ownership. Nobody has written down who maintains the runtime.
The first two are checks you can do today. The third is a decision: name the person or company responsible for the runtime and put it in writing, so the next advisory does not restart the same conversation.
If that person is going to be us, send your website address and hosting provider and we start with a version check.