Host Says PHP Is Updated: How to Check It Is True

Your host wrote: "PHP has been updated." That may be true for one of the five sites on your account, true only for the command line, or true on paper while the running processes still hold the old version in memory. After PHP2Shell such an answer is not enough. Below are four checks a site owner can do alone in fifteen minutes, and a list of questions for the host.

Why "updated" does not yet mean "protected"

• The wrong site was updated. An account may hold several domains, subdomains and test copies, and in many panels the PHP version is chosen for each one separately.
• Only the command-line PHP was updated. The php -v command shows the version for the terminal and cron. In the browser your site is served by a different PHP: PHP-FPM, Apache or LiteSpeed, and these can be different versions.
• The processes were not restarted. The package is updated on disk, but PHP-FPM or Apache workers started earlier keep running the old code until they are restarted.
• The version string can mislead both ways. Linux distributions (Debian, Ubuntu) often backport fixes into a package with an older version number: by the number the site looks vulnerable, but in substance it is already fixed. The opposite also happens.

Check 1. Which version the site itself sees

Without a terminal:

• WordPress: Tools → Site Health → "Info" tab → "Server" section, the "PHP version" line.
• A temporary phpinfo file: a file with the single line <?php phpinfo(); in the site root, open it in the browser and delete it immediately: the page reveals too much about the server to leave it public.
• The response header: the command curl -sI https://your-site.com | grep -i x-powered-by shows PHP/8.x.y unless the administrator has turned this header off. It is often off, and then an empty result proves nothing.

Check 2. Compare with the fixed versions

Fixes were released for branches 8.5 (8.5.12), 8.4 (8.4.27), 8.3 (8.3.36) and 8.2 (8.2.35). For 8.1 and older there is no official fix. Is your version the same as or newer than the matching one in the list? Good. Lower? Do not rush to a conclusion: if the server runs Debian or Ubuntu, ask the host whether the package contains the fixes for CVE-2026-109618 and CVE-2026-109619. The package changelog shows this, and it is easy for a host to answer.

Check 3. Whether the processes were restarted

An update without a restart works only on disk. Ask the host directly: "after the update, did you restart PHP-FPM (or Apache), and when exactly?" If you have SSH, the process start time is visible with ps -eo pid,lstart,cmd | grep -E "php-fpm|apache2|httpd": the start date must be later than the update time.

Check 4. Every place where PHP lives

• All domains and subdomains on the account, including test copies and forgotten old sites: one un-updated site on the account remains an entry point even if the main one is already closed.
• Separate PHP-FPM pools for different sites.
• Cron jobs and command-line scripts: they run on the terminal PHP, not the web one.

What to ask the host

1. What exact PHP version does my site run now (not "8.3", but in full, with the third number or the package number)?
2. Does this package include the fixes for CVE-2026-109618 and CVE-2026-109619?
3. When after the update were PHP-FPM or the web server restarted?
4. Has the same been applied to all my domains and subdomains?
5. If my PHP is 8.1 or older: do you have a package with the fix, or do I need to move to a new branch?

If the host cannot or will not

Some hosts offer only outdated PHP branches. Then two paths remain: move to a branch with the fix (8.2–8.5), first checking on a copy of the site that plugins and modules work, or move the site to a server where you control the version yourself. We do both: PHP update and server hardening is done on a copy of the site, with a compatibility check and a status report.

No check gives a 100% guarantee. It closes typical mistakes but does not replace backups and monitoring.