If you run a website that relies on PHP (along with nearly 70% of the world), you may have seen some fairly alarming security news this week.
Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, have collectively become known as PHP2Shell. Both have been rated 9.2 out of 10 under CVSS v4.0 and can potentially allow an unauthenticated attacker to execute arbitrary code on an affected web server.
Yikes.
Unsurprisingly, some of the technology behind the Framework Training website relies on PHP. When the news broke, we wanted to establish post haste whether our hosting environment was affected and whether the appropriate patches had been applied.
What followed was also a useful reminder of the value of having a responsive web hosting company behind you.
Why PHP2Shell matters
Vulnerabilities in web applications are nothing new. Content management systems, plugins, extensions and application code all have bugs from time to time.
PHP2Shell is more significant, because these vulnerabilities are in the PHP language itself.
PHP is one of the fundamental technologies underpinning a huge number of websites and web applications. The issue therefore potentially sits underneath the application, rather than within a particular CMS, framework or plugin.
The vulnerabilities concern the way PHP handles memory while processing requests. Under particular conditions they can lead to remote code execution without an attacker first needing to authenticate.
In practical terms, that could allow an attacker to execute their own code in the context of the PHP process running on the web server.
That makes patching a priority - by the time the patches became available, attempts to exploit the vulnerabilities were already being observed in the wild.
What we did
Our first step was quite simple: check.
One of the tools we use to manage our website appeared to suggest that the installed PHP version pre-dated the newly patched upstream release.
That left us with an important question. Were we actually running vulnerable software, or had our hosting platform already dealt with the problem?
Rather than make an assumption based on the version number alone, we contacted our hosting provider, Kualo.
They confirmed that the relevant patch had already been applied. Phew! And hats off to them, really.
We also reviewed the security events recorded by Cloudflare, which sits in front of our website and helps inspect and filter incoming web traffic.
As expected for a public website, the logs contained a certain amount of routine automated and unwanted traffic, but we didn't find events that gave us an immediate reason to suspect successful exploitation of PHP2Shell.
That wasn't proof that nobody had looked for the vulnerability, or a substitute for checking the server itself. Cloudflare's security events primarily tell us about requests its security controls have flagged or acted upon. They did, however, give us another useful piece of the picture.
The vulnerability had also been raised through Risk Ledger, the supplier assurance platform we use with some of our customers and partners. We logged the checks we had carried out, Kualo's confirmation that the relevant fixes had been applied, and the outcome of our Cloudflare review before resolving the request.
That step matters because responding to a security alert isn't only about applying a patch. There should also be a record of what was checked, what evidence was obtained and why the issue was considered resolved.
A patched version doesn't always acquire a new version number
Our hosting environment uses CloudLinux, which can backport security fixes into the software packages it maintains.
Backporting means taking the security correction and applying it to an existing release without necessarily moving that installation onto the latest upstream version.
As a result, any software checking only the PHP version number can reach an entirely reasonable conclusion:
This is an older version than the release containing the security fix.
What it can't necessarily see is that the hosting platform has incorporated the same security correction into its own maintained package.
That was the situation Kualo confirmed for us. Although an automated check suggested that our PHP version needed attention, the underlying package had already received the relevant PHP2Shell fixes.
Importantly, we weren't simply relying on the fact that the website was still working or assuming that a managed hosting service would have taken care of everything.
So we raised a support ticket, with the slight expectation of a potentially slow response, given the amount of firefighting going on out there right now.
Kualo was able to very swiftly confirm that the security fixes had been incorporated into the PHP package running within our hosting environment and that we didn't need to make any changes ourselves.
That's the sort of response you want from a hosting provider when a critical vulnerability lands.
How can you check your own website?
If you're responsible for a PHP-based website, we'd recommend positively establishing whether the relevant fixes have been applied.
Check the version you're running
The upstream PHP releases containing the PHP2Shell fixes are:
PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35
If your website reports one of those releases or later, that provides a useful starting point.
If it reports an earlier version, though, don't immediately conclude that the server remains vulnerable. A Linux distribution, hosting platform or long-term support vendor may have backported the security fixes.
Check with your hosting provider
If you're using managed hosting, this may be the most useful check you can make.
You can ask a very specific question:
Can you confirm whether the PHP runtime serving our website has been patched against CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If the displayed PHP version predates the upstream fixed release, can you confirm whether the relevant fixes have been backported into the vendor package we're running?
That gives your provider something concrete to answer.
"We keep our servers up to date" is reassuring.
"We have applied the patches for CVE-2026-109618 and CVE-2026-109619" is considerably more useful.
If you manage your own server, check the package as well as the version
If you're responsible for the underlying Linux server, don't rely solely on something such as:
php -v
That's useful information, but it may not tell you whether your distribution has backported a security patch.
Check the security advisory and package information supplied by your Linux distribution or PHP package vendor as well.
You should also make sure the updated runtime is actually in use. Installing a patched package without restarting the relevant PHP or web-server processes can leave existing worker processes running the older code.
Don't assume updating your website application fixes PHP
If the vulnerability exists in PHP itself, updating your CMS, framework or plugins doesn't by itself update the runtime underneath them.
Both layers matter.
Keeping an application patched is good security practice, but it isn't a substitute for keeping the operating environment supporting that application secure as well.
Be particularly careful with unsupported PHP versions
PHP's normal upstream security releases for this incident cover currently supported branches from 8.2 onwards.
There has been some provision for fixes to older branches, and Linux distributions and long-term support vendors may maintain backported patches. If you're running an older PHP version, however, you need to establish exactly where your security maintenance is coming from.
If nobody is maintaining that version, an incident like PHP2Shell is a pretty compelling reason to plan an upgrade.
Don't publish more diagnostic information than you need to
You may come across advice suggesting that you create or expose a phpinfo() page to inspect your PHP environment.
That can certainly provide useful diagnostic information, but it can also reveal a great deal about the configuration of a server.
We wouldn't recommend publishing a diagnostic page simply to check whether you've been patched.
Use your hosting management tools, package information and vendor security advisories instead. If you're on managed hosting and aren't sure, ask your provider.
You don't need to advertise the inner workings of your server in order to establish whether it's secure.
There's a wider lesson here
Security patching isn't always as straightforward as comparing two version numbers.
Software vendors routinely backport security fixes because upgrading an entire production environment to a new upstream release can introduce compatibility problems of its own.
An apparently older version can therefore contain a current security fix.
But the reverse lesson is equally important.
Don't assume a thing.
When a vulnerability as serious as PHP2Shell appears, take a few minutes to establish what you're actually running, whether it's affected and where the appropriate security fix is coming from.
That's what we did.
The automated warning we received did its job. It prompted us to investigate.
We checked the available Cloudflare security events for signs of suspicious activity, asked Kualo to confirm the state of the hosting environment, and documented our findings in response to the request raised through Risk Ledger.
We didn't find anything in the events we reviewed that gave us immediate cause for concern, while Kualo confirmed that the relevant security fixes had already been applied.
For us, there was nothing further to change, but there was a clear record of what we had checked and why we were satisfied with the outcome.