In short: After the PHP update, you must restart PHP-FPM and all other services that load PHP. New files on disk are not enough as long as old PHP processes are running in memory. Only after the restart does the server work with the corrected code of PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or your provider's backport.
Why you have to restart PHP-FPM
A package update replaces the files on disk. Processes that are already running, however, have already loaded the old program code into memory and keep working with it. PHP-FPM, Apache with mod_php or LiteSpeed often keep their workers alive for days.
For PHP2Shell this is especially important. The vulnerability CVE-2026-109619 hinges precisely on state that persists between requests in the same worker. A worker with old code stays vulnerable, no matter which version is on disk. According to php.net, all workers and processes must therefore be restarted.
Some package managers restart services automatically during the update, others do not. Do not rely on that; check the result.
A typical everyday picture: the package manager reports "PHP updated", monitoring shows no errors, the website runs. Nevertheless the old workers keep serving every request because nobody restarted the service. From the outside, this state cannot be recognised. That is why checking process start times is part of every update.
Which services load PHP?
| Operating mode | What to restart | Typical command (names differ by distribution) |
|---|---|---|
| PHP-FPM | every FPM service, per installed version | systemctl restart php8.3-fpm or systemctl restart php-fpm |
| Apache with mod_php | Apache | systemctl restart apache2 or systemctl restart httpd |
| php-cgi | the calling web server or FastCGI wrapper | depending on setup |
| LiteSpeed | LiteSpeed and the lsphp processes | via LiteSpeed administration or its service |
| FrankenPHP | the FrankenPHP service or container | systemctl restart frankenphp or recreate the container |
| Docker, Kubernetes | recreate containers from the new image | see Patching PHP in Docker containers |
With mod_php, the following applies: the update affects Apache itself, because PHP sits in every Apache process. Why this operating mode is especially delicate is explained at Why mod_php carries the highest risk. For LiteSpeed, you will find details on the page LiteSpeed and LSAPI.
Restarting PHP-FPM: the commands
First find all PHP services on the server. Plesk, cPanel and other interfaces bring their own PHP services with their own names; the list shows them too.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Then restart every PHP service found, not just the first:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # if a second branch is installed
sudo systemctl restart apache2 # with mod_php; RHEL family: httpd
We recommend restart rather than reload. With a reload the main process stays in place; that is intended for configuration changes. After a security update, you want to be sure that every process is new.
If you have additionally applied interim measures such as session.upload_progress.enabled=0 or fixed memory limits, these too only take effect after the restart. One restart takes care of both in one step.
Verifying that no old worker is still running
Compare the start time of the processes with the time of the update. All commands are read-only.
ps -o pid,lstart,cmd -C php-fpm8.3 # on RHEL: -C php-fpm
systemctl status php8.3-fpm # line "Active: … since …"
needrestart -r l # Debian/Ubuntu, if installed
If a process is older than the update, it was not captured. Frequent causes are a forgotten second PHP branch, a separate pool service from a hosting panel, or a container that was merely restarted instead of recreated from the new image. Whether the right version is running is shown on the page Checking the PHP version and patch level correctly.
Documenting the restart
For each server, note the time of the update and of the restart. This moment separates the time in which the server was vulnerable from the time afterwards. For a later check for traces, for insurers and for a possible notification under the GDPR, it is the most important reference point. Also preserve the server logs from 20 October onwards, as the trade press recommends.
On servers with many websites, a short table is worthwhile: server, service, PHP version, package version, time of restart and the person who restarted. That way gaps in coverage are quickly noticed, such as a pool that was overlooked or a test system that nobody had on the list.
How does PHP SOS help?
As part of the PHP patch service, we handle update and restart as one connected process:
- Identify services: We find all processes that load PHP, including those from hosting panels and containers.
- Restart in a controlled way, in agreement with you at a suitable time and with an eye on running orders or forms.
- Verify that no process is older than the update and that the website responds normally.
- Log: versions, package versions and restart times per server.
Frequently asked questions
Is systemctl reload enough instead of restart?
For PHP2Shell we recommend restart. A reload usually restarts the workers, but the main process may keep running. With restart you make sure that no process with old code is left. The brief interruption is offset by clear proof.
Do I have to restart the whole server after the PHP update?
As a rule, no. It is enough to restart all services that load PHP: PHP-FPM, Apache with mod_php, LiteSpeed, FrankenPHP or the affected containers. Restarting the whole server is the simple variant if you are unsure which services use PHP.
Does my hosting provider restart PHP automatically after the update?
That depends on the provider. Ask specifically whether all PHP processes were restarted after the patch, and get that confirmed in writing.