In short: At cloud and PaaS providers, the provider does not automatically patch. If it manages the PHP runtime, it updates it, but often only with the next deployment. If you build images or builds yourself or run the platform yourself, you must rebuild and roll out. What always counts is the runtime that your website is serving right now.
PHP update on PaaS: who owns the runtime?
Platform services, known in the trade as PaaS (Platform as a Service), take server operation off companies' hands. You upload code, and the platform builds and runs it. With PHP2Shell, this creates a typical uncertainty: who actually has to update PHP?
In its bulletin on PHP2Shell, Vercel puts it plainly: updating the local development environment, the application code or the plugins is not enough. What matters is the PHP runtime of the deployment that actually answers requests. Whether this runtime is patched depends on who provides it and when it was last built.
Four operating models compared
Providers' terms differ. For the patch question, most offers can be assigned to one of these models:
| Model | Who updates PHP? | What you have to do |
|---|---|---|
| Runtime managed by the provider | Provider | Obtain confirmation, redeploy if needed so that the new runtime takes effect |
| Build-based runtime (buildpack) | Provider makes a new version available, your build pins it | Trigger a new build, check the version in the build log |
| Your own container image | You | Rebuild the image with fixed PHP and roll it out |
| Self-operated platform | You, for platform and applications | Patch the platform and each application individually |
Many companies use several models at once, for example a managed runtime for the website and their own containers for internal tools. Every application therefore needs its own answer.
A trap lurks in the word "managed". Even when the provider maintains the runtime, an application that has already been rolled out often continues to run with the version it was built with. The new version then takes effect only at the next build or deployment. Some platforms also keep older deployments or preview environments reachable at their own addresses. So do not only ask whether the provider has patched, but also from when your running instances use the patch and what happens to old deployments.
What Vercel and Coolify say about PHP2Shell
Two providers have made their guidance public. They are instructive because they state the limits of their own protective measures clearly.
Vercel, according to its own bulletin, activated protection rules in its web application firewall (WAF), a filter for web requests, before publication. They apply automatically to PHP functions on Vercel and to requests that Vercel forwards to external PHP servers. At the same time, Vercel demands that the PHP runtime be updated immediately to a fixed version. Container deployments are to be rebuilt with an updated PHP base image and rolled out. Requests that bypass Vercel and go directly to an external PHP server are not covered by the WAF.
Coolify, a self-hostable platform, was itself affected according to its own advisory: all branches of version 4. As the first fixed versions, Coolify names 4.0.1, 4.1.3, 4.2.1, 4.3.24 and 4.4.7 and recommends 4.4.7. The addition is important: the Coolify update does not update the PHP applications you run through it. Their runtimes or images must be updated separately and rebuilt or rolled out. According to Coolify, this also applies to Coolify Cloud customers and also behind Cloudflare, because Cloudflare rules only inspect traffic that passes through Cloudflare.
What Cloudflare rules achieve is put into perspective by the article Cloudflare protection rules against PHP2Shell.
How to check the serving runtime
The following steps work regardless of the provider. They aim at proof, not at a feeling.
- List all environments: production, staging, preview deployments and background services such as queue workers. Each environment can have a different runtime.
- Read the runtime version per environment: in the provider's console, in the build log or in the project's configuration file.
- Check the date of the last deployment: if it is before 21 October 2026, the old runtime is very likely still running unless the provider expressly confirms otherwise.
- Look in the running instance: if the platform offers a console, the following command shows the instance's version.
- Include external PHP servers: servers to which the platform forwards requests need their own update and should not be reachable directly from the internet.
# In the console of the running instance (if offered by the provider)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Expected are 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a backport confirmed by the provider. Note that an instance's command line does not always use the same runtime as the web process. Do not create a publicly reachable phpinfo file for the check. How to interpret version number and backport status correctly is described in Checking the PHP version and patch status.
A new deployment does not remove malware that previously got into persistent storage such as upload volumes or the database. Check these areas separately.
Put responsibility in writing
PHP2Shell shows how unclear the boundary between platform and customer often is. For each application, record who provides the runtime, who rebuilds on security announcements and how the provider announces patches. This also includes who has access to the platform console when time is short, and who may trigger a new build outside business hours.
For your own documentation, a short table per application is enough: platform, operating model, PHP branch, date of the last build, person responsible. Whoever has this list at hand at the next announcement saves the days that many teams spent searching after 21 October. For container applications, this includes who maintains the base image; background is explained in PHP in containers.
For managed servers without PaaS character, similar questions apply, which we have summarized under Managed server: clarifying responsibility.
How does PHP SOS help?
- Assign: We assign each of your applications to an operating model and clarify who provides the PHP runtime.
- Prove: We check runtime, build date and deployment per environment and document the result.
- Rebuild and roll out: Through the PHP patch service, we update images and builds and roll them out in a controlled way.
- Close gaps: We check whether external PHP servers are directly reachable and restrict access.
Frequently asked questions
Does my PaaS provider patch PHP automatically?
That depends on the model. If the provider manages the runtime, it updates it, but often only for new deployments. If you build images or builds yourself, you must rebuild and redeploy. Have the status confirmed for your application.
Is my platform provider's WAF enough against PHP2Shell?
No. Vercel and Coolify state explicitly that protection rules do not replace updating the PHP runtime. They also act only on traffic that passes through the platform.
Do I have to redeploy after the patch?
Often yes. For container deployments, Vercel calls for rebuilding with an updated PHP base image and a new deployment. On build-based platforms, the runtime is fixed at build time; only a new build picks up the patch.
I use Coolify. Is the Coolify update enough?
No. According to the Coolify advisory, the update only updates Coolify itself. The PHP runtimes or container images of your applications must be updated separately and rebuilt or redeployed.