When “just update PHP” becomes a small investigation
There is a particular kind of advice that sounds perfectly reasonable until you have to put it into practice:
“Your PHP version is outdated. Just update it.”
Technically, that is correct. Practically, it can be the beginning of a very long afternoon.
On 21 October 2026, the PHP project released emergency security updates for two critical vulnerabilities known as PHP2Shell: CVE-2026-109618 and CVE-2026-109619. These flaws can allow unauthenticated remote code execution in affected PHP environments.
The recommended action is straightforward: install a patched PHP release.
But what happens when the website you need to protect is several years old, runs WordPress, has a collection of plugins, uses a commercial theme, and may have WooCommerce somewhere in its history?
That is where the interesting part begins.
First, find out what is actually running
Before changing anything, I needed to establish which of the websites under my maintenance were running affected PHP versions.
A hosting control panel does not necessarily tell the whole story. Public HTTP response headers can sometimes reveal the PHP version, but these headers can also be hidden. And even when a version is visible, it tells us what the server reports, not necessarily whether the installation has received the relevant security patch.
A simple inventory quickly identified several websites running older versions of PHP, including PHP 5.6, 7.2 and 7.4.
The obvious next step was to upgrade them.
Except that there was no single upgrade button that could safely solve the problem for every website.
The first surprise: the website went completely white
I started with an older WordPress installation running PHP 7.4.
Switching to PHP 8.3 immediately broke both the public website and the administration dashboard. PHP 8.2 did not provide a complete solution either.
The website was not necessarily compromised. It was simply unable to execute some of its existing code in the new environment.
This distinction matters.
PHP is the engine that executes WordPress and its plugins. When that engine changes, old code may encounter removed functions, stricter behaviour or dependencies it cannot satisfy.
A plugin can work perfectly for years and still prevent a website from starting after a PHP upgrade.
The obvious reaction is to switch back to the old version. That restores service, but it does not solve the security problem.
Now we have two competing priorities: keep the website operational and move it to a patched environment.
Then the update mechanism failed
The next step was to modernise WordPress and its extensions.
Except WordPress could not reliably download its own update.
The error was:
cURL error 60: SSL certificate OpenSSL verify result: unable to get local issuer certificate
In simple terms, the server could not validate the certificate chain required for the download.
This is an important detail. It was not proof that WordPress.org had a bad certificate, nor did it necessarily mean that the website’s HTTPS certificate was broken. The problem was in the environment used to make the outgoing connection.
So the task changed again.
Before I could finish updating the website’s software, I had to find another way to update the WordPress core itself.
Using the hosting control panel’s WordPress management tool, I was able to move the installation from an old 5.x release to the newer 7.x series.
That was progress, but we still had an outdated PHP runtime and plugins whose compatibility had not yet been established.
WordPress is not just WordPress
An old WordPress website is rarely a single piece of software.
It is a collection of dependencies that have accumulated over time:
- The WordPress core.
- A commercial theme, sometimes with its own framework and shortcodes.
- Plugins maintained by different developers.
- Database drivers and PHP extensions.
- External libraries and dependencies managed through tools such as Composer.
- Features that may no longer be used but whose files remain on the server.
WooCommerce adds another layer when a website uses it, particularly when payment gateways, checkout customisations or other commerce extensions are involved.
In this case, the installation had a theme designed to support WooCommerce, along with WooCommerce and a payment extension among its inactive plugins. Other active plugins still needed to be checked against the new PHP environment.
Updating one component does not guarantee that the others will work.
In fact, updating a plugin can introduce a new requirement. One of the updates in this process explicitly required PHP 8.3 or higher. That meant PHP 8.2, which had been useful for troubleshooting compatibility, was no longer sufficient for that particular component.
The solution was not simply to keep trying different PHP versions. It was to understand which component required what, and why.
The difference between EA-PHP and Alt-PHP
The hosting control panel introduced another complication.
It offered two PHP environments: EasyApache PHP (EA-PHP) and CloudLinux Alt-PHP.
Both can run PHP, but they are not necessarily configured identically. The available versions, extensions and settings can differ.
The EA-PHP options available to me stopped at PHP 8.1, while the patched PHP 8.2 and 8.3 options were available through Alt-PHP.
Switching environments was therefore not just a version change. It also meant checking the extensions WordPress needed to communicate with the database, process images and handle other tasks.
A website that fails to load after a PHP switch is not automatically suffering from an incompatible plugin. The cause might be a missing extension, a configuration difference or a genuine code incompatibility.
That is why diagnosing the failure matters more than repeatedly changing settings and hoping for the best.
One change at a time
After restoring access to the administration area, I used the hosting control panel’s WordPress Manager to disable the plugins temporarily.
The dashboard came back.
That gave me useful evidence: at least one plugin, or an interaction between plugins, was contributing to the failure in the new environment.
From there, I could isolate the components, test them individually and examine the errors they produced. Updating Contact Form 7 exposed a Composer requirement for PHP 8.3, which helped explain why the lower PHP version could not remain the final solution.
Eventually, after resolving the PHP environment and its required extensions, the site was running on PHP 8.3.36. The WordPress status report confirmed the expected runtime and database connectivity.
That was a much better outcome than merely seeing the homepage load.
A successful homepage is not proof that checkout, forms, administration, scheduled tasks or every other feature works correctly. Those still need appropriate testing.
The security lesson
The PHP2Shell vulnerabilities are serious. The PHP project published patched releases for the supported branches:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
The correct target depends on the PHP branch and the hosting provider’s available, supported packages. Older branches require particular care because they are no longer generally supported; any vendor-provided security backport must be verified rather than assumed.
The immediate objective is to get onto a patched runtime. The longer-term objective is to stop depending on software that cannot safely move forward.
For older WordPress websites, that may mean replacing abandoned plugins, removing unused components, reviewing the theme, testing backups and planning a more substantial rebuild.
It also means testing more than the front page after an upgrade.
A website that loads is not necessarily a website that works. And a website that works is not necessarily a website that is secure.
My verdict
Security advisories usually describe the destination: install the fix.
Real websites make you deal with the journey.
An old WordPress installation can have years of code, configuration decisions and third-party dependencies behind what appears to be a simple website. A PHP upgrade can expose problems that have remained invisible for years, while the old runtime may itself prevent the software updates needed to move forward.
This is why “just update PHP” is not always a responsible maintenance plan.
The correct approach is to establish what is running, back up the installation, understand its dependencies, move to a patched runtime, resolve compatibility problems and test the result.
It is more work than clicking a button.
Routine maintenance keeps the lights on; critical security architecture overhaul is a distinct, billable engineering service.
Stay curious. Verify the fix. Test what matters.
This article describes a real maintenance and troubleshooting process. The website and client have been left unnamed. The technical sequence illustrates the complications encountered during this particular upgrade; it is not a universal upgrade procedure for every WordPress installation, if you need help troubleshooting your website fell free to contact me.
