On 21 October 2026 at 14:00 UTC the PHP team published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. We started about an hour later. Around 17:00 UTC all servers we maintain were closed: 88 projects under our support. This post covers how we did it and what slowed us down, because the same obstacles sit on many servers that nobody has patched yet.
If you only need to know whether your site is affected and what to ask your host, read our first post on PHP2Shell.
Hour one: cut the attack path everywhere
A fixed PHP takes time to install on dozens of servers. Switching off the vulnerable mechanism takes minutes. So we did that first, on every server, before building anything.
The PHP advisory names session.upload_progress.enabled as one of the paths for CVE-2026-109619. We set it to off in the main PHP configuration of every PHP version on every server and restarted the PHP workers. The advisory warns that .user.ini and ini_set() don’t count, so we changed the server-level files. On PHP 8.5 we also switched off fatal_error_backtraces, as the advisory suggests.
This closed the confirmed session path of CVE-2026-109619 only. CVE-2026-109618 needed the update itself.
Three kinds of servers, three ways to patch
Our 88 projects run on a mix of setups, and each needed its own route.
Servers with PHP from distribution packages. Here the fix comes from the package maintainers. Ubuntu published fixed packages on release day. One catch for anyone checking such a server: after the update php -v can still show the old number, for example 8.3.6, because Ubuntu patches the package and keeps the version. Check the package version instead.
Servers run through a hosting control panel. Several servers use aaPanel, which builds its own PHP. On release day the panel had no updated PHP. Waiting for the panel meant leaving these servers open for an unknown time, so we built PHP ourselves.
Docker containers. Some projects run PHP inside containers built from existing images. Rebuilding and redeploying a whole application in the middle of an incident adds risk. We patched the PHP inside the running containers instead and scheduled proper image rebuilds for later.
Building PHP ourselves without breaking the panel
A panel’s PHP build differs from a stock one. If you build PHP with default options and drop it in, extensions go missing, and the panel stops recognising its own PHP.
We wrote one build script and ran it per PHP version on each panel server:
- it reads the exact configure options from the PHP already installed, so the new build has the same extensions and paths;
- it builds the fixed version from the official source;
- it checks which OpenSSL and curl libraries the new binary links against. The panel links some PHP versions to its own older copies of these libraries, so the script makes sure the new build uses the same ones;
- it backs up the old binaries, installs the new ones and restarts PHP;
- if PHP fails to come back, it restores the old binaries on its own.
The script let us patch one PHP version on one server, check the sites, and repeat on the next without hand work each time.
PHP 7.4, 8.0 and 8.1: no official release
The PHP team no longer releases these branches. For PHP2Shell it published only the source changes for 7.4, 8.0 and 8.1. Some of our projects still run these versions.
For those we applied the PHP team’s source fixes to the last release of each branch and built it with the same script. The published changes also touch version files and changelogs, which do not apply cleanly to a release, so we applied only the code changes.
One server ran PHP 7.4 from Ubuntu 20.04 packages. For that Ubuntu release the fix comes only through Ubuntu’s extended security maintenance (ESM), which that server does not use. We built PHP 7.4 with the same build flags Ubuntu uses and replaced only the PHP-FPM binary, keeping the original next to it. A later package update would overwrite our build, so we noted that in the project’s records.
Containers: patched now, rebuilt later
For each container we built the fixed PHP in a clean copy of the official image for the same operating system, then copied only the PHP binaries and the extensions it needed into the running container, with a backup of the originals inside.
One Alpine-based image needed the same extra source patches that the official PHP Docker image applies, or the build failed with a newer compiler.
The catch with this approach: the fix lives only until someone recreates the container from the old image. If your team patched containers this way, put an image rebuild on the plan, or the vulnerability returns with the next deploy.
After the patch: logs
Once every server ran a fixed PHP, we went through the web server and PHP logs on all servers for requests that matched how the vulnerabilities could be used. We found no signs of exploitation.
What we would tell a site owner after that evening
- Your host’s speed is your speed. If your PHP comes from a panel or a provider who waits for it, your site stays open until they act. Ask them today what version you run.
- Old PHP still costs you. PHP 8.1 and older got only source code fixes this time. Next time there may be none. PHP 8.2 support ends on 31 December 2026.
- Containers and custom builds need an owner. Nobody updates them automatically. Someone has to know they exist and how to rebuild them.
Our automated monitoring runs around the clock, and our engineers respond when it raises an incident.
If you need the same for your servers
We’ll check your PHP version and update it within one working day. Write to us.
For ongoing care see server support, website support and DevOps. If your mobile app talks to a PHP backend, that backend needs the same update; we cover it under mobile app support. To find out whether anything else is open, order a penetration test.
Sources
- PHP team announcement and mitigations: https://www.php.net/archive/2026.php
- Security advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available