Checking the PHP Patch Version on a Rental Server: October 2026 Vulnerability Response

Introduction

On October 21, 2026, two critical PHP vulnerabilities were disclosed. They could allow a remote attacker to run programs on the server without logging in.

I support a web production company as a technical advisor. Many of the corporate websites that company manages are WordPress sites running on rental servers. I handled the investigation and the recommendations, and the directors in charge of each client carried out the actual work.

During the response, I learned that my assumption that the hosting provider was applying patches was wrong. On one rental server, PHP had stayed at the version from May.

This article covers four things:

• Why the rental server's control panel alone could not tell me the PHP patch version
• How to confirm the PHP version actually in use, using WordPress Site Health and SSH
• How the providers differed in what I found, and how I took sites offline and waited
• Options beyond WordPress

It is aimed at companies that run their websites on WordPress. I do not go into how the vulnerabilities work.

1. What was disclosed

Two vulnerabilities were disclosed: CVE-2026-109618 and CVE-2026-109619. Both have a severity of 9.2 under CVSS v4.0. They could allow remote code execution without authentication. The affected code is every PHP installation that handles web requests.

The fixed versions are the following four (announcement on php.net):

Minor version	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

The PHP project does not release fixes for 8.1 and earlier. Also, php.net states that mitigations such as configuration changes do not make a system safe, and that updating is the only complete fix.

2. I had assumed the hosting provider applied the patches

The rental server's control panel has a drop-down for choosing the PHP version. However, the choices only showed minor versions, such as "8.5." Patch versions like 8.5.12 were not displayed, and I could not select them.

I had taken this to mean that the provider applies patch versions automatically. The division of roles, as I understood it, was that the customer picks the minor version, and the provider keeps the patch level up to date.

I went into this vulnerability without checking that assumption.

3. Checking the patch version

If the rental server's control panel does not show it, I need another way to check. If you can log in to the WordPress admin, Site Health is the quickest option. I did not have permission to log in to the WordPress admin, so I checked over SSH.

3-1. Checking with WordPress Site Health

In the WordPress admin, open Tools → Site Health → Info tab. In the Server section, the PHP version is shown with the patch version included, for example 8.5.6 (supports 64bit values). WordPress itself displays the value of the PHP constant PHP_VERSION here (Site Health screen). This is the PHP version that actually processes your site.

3-2. Listing the PHP installed on the server over SSH

On one provider's server, the PHP executables were installed for each minor version.

ls /usr/bin/php*

This shows command-line PHP commands such as php8.2 through php8.5. It also shows web (FastCGI) PHP binaries such as php-fcgi8.2 through php-fcgi8.5. I displayed the version for each one together.

for v in 8.2 8.3 8.4 8.5; do
  echo "== $v"
  php$v -v | head -1
  php-fcgi$v -v | head -1
done

The first line shows the patch version and the build date, for example PHP 8.5.12 (cli) (built: Oct 21 2026 ...). The location and names of the executables differ by provider, so check them with ls first.

3-3. Checking which PHP serves the web over SSH

Running php -v over SSH only shows the command-line PHP. It is not necessarily the same PHP that serves your site. So I placed a temporary file in the site's public directory and opened it through the web to check.

f=v$RANDOM.php
echo '<?php echo PHP_VERSION;' > ~/public_html/example.com/$f
curl -s https://example.com/$f; echo
rm ~/public_html/example.com/$f

The output is the version of the PHP that actually processes that site, such as 8.5.6. It is the same value shown in Site Health. I included $RANDOM in the file name so it is hard to guess, and I deleted the file right after checking. The path of the public directory differs by provider.

3-4. Comparing against the fixed version numbers

Compare the version you found with the fixed versions in the table in section 1. For example, on the 8.5 line, 8.5.12 or later includes the fix. 8.5.11 or earlier has not been fixed yet. If the version shows as 8.1 or earlier, you cannot judge by the version number. You need to move to a supported version. How to respond when a site is not fixed is covered in section 5.

4. What the checks showed

The results differed clearly between the two providers.

The first provider finished updating on the day the fixed versions were released. Every version from 8.2 through 8.5 was a fixed release (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12), with a build date of October 21. This provider had announced on social media that it had applied its own patches even to PHP versions that the upstream project no longer supports.

The second provider's site returned 8.5.6 over the web. The 8.5.6 release came out on May 7, 2026 (PHP Releases). The 8.5.7 through 8.5.11 releases that came after it had not been applied either, so updates had been stopped since May.

5. Unable to reach the rental server's control panel, I took the sites offline and waited

After the disclosure, rental server providers were busy updating their versions. Many providers went into maintenance, and their control panels were unavailable.

The rental server's control panel only lets you choose minor versions, and there is no way for the customer to apply a patch. So for sites that had not been fixed, I decided to take them offline and wait for the provider to finish updating. I expected it to take at least a day.

I did not keep the sites open while waiting. If the vulnerability was exploited in the meantime, personal information could leak, or the server could be abused. With no idea when the update would finish, I did not think it was an appropriate decision for a production company to keep the sites open while waiting. On the morning of October 23, the update was complete.

6. Make sure you can reach the server over SSH, even on a rental server

This time, SSH was the only way I could confirm the actual version. I did not have permission to log in to the WordPress admin. The rental server's control panel only showed minor versions, and during the incident I could not even get into it.

Even if you use a rental server, you should set up SSH access in advance. Enable SSH, register your key, and confirm that you can actually log in. If you start from the settings only when you need it, checking will be delayed.

7. Options beyond WordPress

WordPress has many reported vulnerabilities, not only in the core but also in plugins. And since it runs on PHP, it is exposed to PHP vulnerabilities like this one. When there is a chance to rebuild a site, options other than WordPress are worth considering.

The options I suggest are these three:

• Markdown + Cloudflare Workers: Write articles in Markdown, generate the site statically, and serve it from Cloudflare Workers. This site is built this way too, and no PHP runs on the server
• Headless CMS: Separate the article editing admin from how the site is displayed. The display side can be generated statically and delivered
• EmDash: A TypeScript CMS based on Astro, announced by Cloudflare in April 2026. It positions itself as a successor to WordPress and runs plugins in isolated environments (EmDash 1.0 announcement)

Closing

The rental server's control panel only showed minor versions. Whether a patch has been applied cannot be known until you check it yourself.

Start by checking the patch version of your own site's PHP, using Site Health or SSH. If you cannot log in over SSH, the first step is getting it set up.