How to update PHP on your server or hosting: the step-by-step guide

Updating PHP is the only complete way to fix the critical flaws published on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619, covered in our article on the PHP vulnerability). The catch is that the procedure depends entirely on how your site is hosted: on managed hosting someone does it for you; on a VPS nobody will. This guide walks through each case, then the checks that confirm the fix is actually active.

Step 0: know where you stand

Before touching anything, note the current version of every installation. Three methods depending on your access:

• On the command line: php -v shows the version the terminal uses. On a server with several versions installed, ls /etc/php lists them all, and php8.4 -v (or php8.3 -v) queries a specific one.
• From WordPress: Tools, then Site Health, Info tab, Server section.
• From a hosting panel: cPanel shows it under "Select PHP Version" or "MultiPHP Manager"; Plesk under each domain's PHP settings.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Any lower number in the same branch is vulnerable. PHP 8.1 and older have no fix: go straight to migrating to a supported version.

Case 1: managed WordPress or shared hosting

On managed hosting (turnkey WordPress plans) or classic shared hosting, the host updates PHP on its servers. Your job is to confirm they did.

1. Check your host's status page or emails. The large providers communicated on 21 October.
2. If you have heard nothing by the end of the day, open a support ticket asking explicitly whether the PHP release of 21 October 2026 has been applied.
3. In your panel, check which PHP branch is selected for your site. If it is 8.1, 8.0 or 7.4, switch to 8.3 or 8.4 after a test (see the migration article).
4. After the update, walk through the key pages: home, forms, cart and checkout if you sell online.

On cPanel, the PHP handler matters too. If your server runs Apache with mod_php (sometimes called DSO), the risk is highest; ask the host whether they can switch to PHP-FPM, which also improves performance.

Case 2: VPS or dedicated server on Ubuntu or Debian

Here nobody updates PHP for you, and Ubuntu's automatic security updates do not cover PHP installed from a third-party repository (Ondřej Surý's packages, used by most Laravel servers and by tools such as Forge). The procedure:

1. Refresh the package lists: sudo apt-get update.
2. Check which version will be installed: apt-cache policy php8.4-fpm. The "Candidate" line must show 8.4.27 (or your branch's equivalent). If not, the repository has not received the packages yet: try again a little later.
3. Upgrade every package of the branch, without installing new ones and keeping your configuration files: sudo apt-get install --only-upgrade -y -o Dpkg::Options::="--force-confold" $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}').
4. Repeat for every installed version, including those no site currently uses (a site may be switched to it later).
5. Check that PHP-FPM restarted: systemctl status php8.4-fpm. If not: sudo systemctl restart php8.4-fpm. With Apache and mod_php: sudo systemctl restart apache2.

On packages shipped by Debian or Ubuntu themselves (no third-party repository), the fix may be backported without changing the displayed version number. apt changelog php8.2 or the package changelog then tells you whether CVE-2026-109618 and 109619 are mentioned.

Case 3: server with cPanel or Plesk

Control panels ship their own PHP builds. On cPanel/WHM, EasyApache versions update through the server's automatic updates or manually in WHM (EasyApache 4, then package updates). On Plesk, the Plesk-provided versions update from Tools & Settings, Updates. If you use CloudLinux, the alternative PHP versions follow their own cycle, and Imunify360 publishes blocking rules which, according to the vendor, block the public exploit on Apache but only log it on LiteSpeed. In every case, verify afterwards that each domain uses a fixed version.

Case 4: Docker and containers

A container image freezes the PHP version it contains. Updating the host server changes nothing: you have to rebuild the image from a fixed base image (for example php:8.4-fpm republished after 21 October, or your framework's official image), then redeploy. Check the version inside the running container with docker exec <container> php -v. If you use FrankenPHP, which is also affected, wait for the image rebuilt with fixed PHP.

Final step: restart long-running processes

The package update restarts PHP-FPM, but not the PHP processes started from the command line that run continuously: queue workers, Laravel Horizon, Octane, Reverb, long scheduled tasks, home-made daemons. They keep the old PHP version in memory until they are relaunched. For a Laravel application: php artisan queue:restart, php artisan horizon:terminate, php artisan octane:reload. For a service managed by Supervisor: supervisorctl restart all.

Verify that the fix is active

• php8.4 -v and php-fpm8.4 -v must both show the fixed version.
• A temporary phpinfo() page (delete it afterwards) confirms the version served over the web, which can differ from the terminal's.
• On WordPress, Site Health must show the new version.
• Walk through the critical journeys: login, contact form, order, customer area.
• Watch PHP error logs and response times for the next 24 hours.

If the update breaks something

A minor update (8.4.26 to 8.4.27) does not change the language's behaviour and very rarely breaks a site. If a problem appears, it usually comes from a PHP extension compiled for the old version or an opcode cache to clear (opcache_reset() or an FPM restart). A branch change (8.1 to 8.4) is a different matter: old extensions or plugins can fail, which is why a staging environment matters.

Hand off your updates

If this procedure feels heavy for a Tuesday afternoon, it is exactly what our managed services cover: version inventory, update on staging then production, service restarts, journey checks and monitoring. Not sure who manages your server? Write to us and we will work it out.