In short: If you want a PHP update installed, you need more than new packages: what matters is the right package version, the restart of all PHP processes and proof of both. That is exactly what our PHP patch service delivers. You receive a written record for each server that you can present internally or to third parties.
Why a PHP update alone is often not enough
Since 21 October 2026, patches have been available for the PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619. The BSI (German Federal Office for Information Security) recommends updating immediately. In practice we see three typical pitfalls.
First, the version number does not always show the true state. Distributions and hosting providers sometimes apply backports; Plesk, for example, then keeps reporting 8.2.34 although the package is patched. Second, old PHP processes often keep running after the update is installed. New files on disk offer no protection as long as the old workers are still working in memory. Third, several PHP versions often run in parallel on one server, and one of them gets forgotten.
Having a PHP update installed: the fixed versions
| Branch | Fixed from | Previous version | Note |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | also check fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | support ends on 31 December 2026 |
| PHP 8.1 and older | no official updates | – | only minimal source backports for 7.4, 8.0, 8.1 |
For packages from distributions or hosting providers, what counts is not the number after "PHP" but the package version that the provider confirms as patched. How to check this yourself is described at Checking the PHP version and patch level correctly.
How does PHP SOS help?
- Inventory: We record all PHP installations on the server, the operating mode (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) and which website uses which version.
- Installing the update: We install the fixed versions from the package source of your distribution, your panel or the official project. For containers, we build new images with you.
- Restart of all processes: We fully restart PHP-FPM, Apache, LiteSpeed or the respective workers and check that no process is older than the update. Background is available at Restarting PHP-FPM and all workers.
- Functional check: We call up the most important pages and functions, such as the home page, login, forms and checkout, and check the error logs.
- Record: You receive a log for each server with version, package version, time of the restart and open items.
A typical check after the restart looks like this:
# version of the PHP CLI and of the FPM binary (path depends on the system)
php -v
php-fpm8.3 -v
# start time of the FPM processes: must be after the update
ps -o pid,lstart,cmd -C php-fpm8.3
Special cases: panels, containers and multiple PHP versions
On servers with Plesk or cPanel, PHP versions often come from the panel's package sources and not from the distribution. There we check every installed version individually, including those not currently assigned to any website. By arrangement, we remove unused, outdated versions so that they are not reactivated by accident.
In Docker and Kubernetes environments, an update on the host is not enough. PHP is part of the image, and only a newly built image with a patched base, rolled out to all running containers, closes the vulnerability. We also check whether older images in registries or deployments are still in use. Details are at Patching PHP in Docker containers.
With mod_php, PHP runs directly inside the Apache process. The PHP team rates the risk there as highest. After the update, Apache itself must therefore be fully restarted; simply reloading the configuration is not sufficient in every case.
What you get from us
- a patch log for each server: installed packages, versions, source, time
- proof that all PHP processes have been restarted
- a list of the websites and functions checked
- notes on systems that could not be patched, with the reason
- a recommendation for the way forward, for example for PHP 8.2 because its end of support is near
What we need from you
- Access: SSH with administrator rights or panel access (Plesk, cPanel or similar)
- Maintenance window: when a short restart is allowed
- Contact person: for questions and for sign-off after the functional check
- Backups: confirmation that a current backup exists, or the order to create one beforehand
- Notes on custom developments: special PHP extensions or configurations that need to be taken into account
With shared hosting without your own server access, we cannot patch ourselves. We then help you ask your hosting provider the right questions and assess the answer.
What we do not promise
The patch service closes the known vulnerability. It does not answer whether the server was already compromised before the update, and it does not remove malware that has been planted. If you want to know that, the PHP2Shell emergency help with its search for traces is the right engagement.
There are no official updates any more for PHP 8.1 and older. Here we apply interim measures and recommend the migration to a supported version. We do not give a compatibility assurance for your CMS from memory, but check it against the manufacturer's system requirements.
Frequently asked questions
Why does my server still show the old PHP version after the update?
There can be two reasons. Either the distribution applied a backport, in which case the version number stays the same even though the package is patched. Or old PHP processes are still running in memory and need to be restarted.
Which PHP versions close PHP2Shell?
The vulnerability is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. For distribution packages, what counts is the package version that the provider confirms as patched.
Can the update take my website down?
An update within the same major version, for example from 8.3.35 to 8.3.36, is usually uncritical. A short restart of the PHP processes is necessary, though. We agree the time window with you and check the pages afterwards.
Is everything done once the patch is applied?
For the vulnerability itself, yes, as soon as all processes have been restarted. The patch does not show whether someone broke in before it was applied. That requires a separate check.