When the PHP security team released urgent fixes for two critical remote code execution vulnerabilities on 21 October 2026, every provider running PHP had a decision to make: wait for the next routine maintenance window, or check each affected system and act as soon as a trusted package was available.
We chose to check the systems serving DCX customers and move quickly, while keeping the work controlled and verifiable. The release addressed CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. The PHP project published fixes in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
First, find the PHP that actually serves the site
A server can have several PHP installations at once. A command-line binary may report a fixed version while a website still runs an older PHP-FPM pool, an Apache module or a control-panel runtime. Updating the first version shown by php -v is not enough.
We mapped each VPS and hosting service to its operating system, control panel, package source and active web handler. We checked the installed and running PHP versions separately, including FPM services and PHP versions used only for command-line jobs. That distinction matters: a CLI-only version does not serve HTTP requests, while a forgotten FPM pool can remain exposed even after another PHP version has been updated.
Package evidence matters more than the version string alone
Linux vendors sometimes backport a security fix without changing the upstream version number. Debian documents this approach and recommends checking the exact package revision and security changelog. We therefore checked the vendor package metadata and security changes for the repository in use, rather than declaring a package vulnerable or fixed from its major and minor version alone. On systems using third-party PHP repositories, we also verified the signed package source.
Where an upstream release was available, the target builds were PHP 8.2.35, 8.3.36 and 8.4.27 for web workloads, plus PHP 8.5.12 where it was installed for command-line use. Ubuntu and vendor-maintained branches can use a different package version while carrying the relevant security fix, so those were evaluated against their own package evidence.
Maintenance inside a VPS, with the right access path
A VPS is a complete guest operating system, not just a disk image attached to a host. Where QEMU Guest Agent is enabled, the virtualization layer can communicate with the guest and run a scoped maintenance action without opening a new public SSH port. The QEMU documentation describes this guest execution interface. We use the access path available and approved for each system, and record what was checked and changed.
The update itself follows the guest’s package manager and repository. We preserve customer configuration where possible, inspect package changes before applying them, and avoid turning a focused security response into an uncontrolled operating-system release upgrade.
Apply, validate, then reload
Replacing package files is only one part of the job. We validate the relevant PHP-FPM configuration and the web-server configuration before reloading services. We then check that the expected FPM pools and web services are active and that the site responds. Where a reboot was part of the approved maintenance, we repeated the health checks after boot.
This process helps keep service interruption low and makes it easier to spot a problem while the change is still understood. It also creates a clear record: which runtime was active, which package source supplied the fix, which services were reloaded, and what the post-update checks showed.
Control-panel PHP is a separate responsibility
Some control panels bundle their own PHP runtime for the administration interface. That runtime is separate from the PHP-FPM version serving a customer’s website, so patching the website handler does not automatically patch the panel.
On 21 October 2026, Plesk’s advisory listed the website PHP fixes separately from the internal sw-engine fix for its panel. We tracked that panel component as a separate vendor item. Some myVesta systems also retain a legacy PHP runtime inside the panel. A private panel URL can reduce casual exposure, but it does not update PHP or replace a vendor security fix. We keep these limitations visible instead of calling an access restriction a patch.
Older PHP branches need the same honesty. A trusted vendor backport can close a particular vulnerability, but it does not restore upstream support or guarantee future fixes. We identify those cases and recommend planning a move to a supported branch.
Security work should leave customers with clear answers
Customers should not have to guess which PHP version their website uses, whether an update reached the active FPM pool, or whether a control panel is still waiting for its own fix. Our maintenance process checks those layers separately and reports what was updated, what was validated and what remains with a software vendor.
If you run a DCX VPS and want help planning PHP or operating-system maintenance, contact our team. We can review the panel, PHP handlers and package sources on your server, then agree on a maintenance scope that fits your workload.
Sources: PHP security advisory, Debian Security FAQ, QEMU Guest Agent protocol, and Plesk’s advisory.