How to check which PHP version a site runs

From outside: what is public

The PHP version leaves the server in exactly one place — the X-Powered-By response header. If expose_php is on (the default in a stock php.ini), the header reads X-Powered-By: PHP/8.3.29 and that value is a fact, not an inference.

# ask for the headers only
curl -sI https://example.com/ | grep -i 'x-powered-by\|^server'

# some setups send the header on .php responses only
curl -sI https://example.com/index.php | grep -i x-powered-by

If both commands print nothing, the version is hidden. That is the normal case: in the sites we checked while building this service, not one disclosed the build in a header. Faced with a hidden header, a lot of “PHP vulnerability scanners” quietly invent a version or label the site “safe” — neither is information.

Two other public signals narrow things down without giving a number:

• That the site runs PHP at all. A PHPSESSID cookie, .php links, a /wp-content/ path or a Bitrix marker are enough to say “PHP”.
• Where the version leaks anyway. An open phpinfo(), a reachable PHP-FPM status page, a debug toolbar or a composer error page publish the exact build without any header at all. Checklamp flags those separately, because a removed X-Powered-By next to an open /phpinfo.php is a false sense of safety.

From inside: the proof

One command on the server settles it. Run it the way the site is served — not in a terminal on your laptop.

# CLI build
php -v

# the FPM binary of a specific branch, if FPM is used
php-fpm8.3 -v

# Debian/Ubuntu: which versions are installed and which is default
update-alternatives --list php || ls /etc/php

# the container that actually serves the site
docker exec -it <container> php -v

Read the first line: PHP 8.3.36 (cli) is the build. Anything on the same branch starting with 8.3. is that branch, and branches are patched as a whole — 8.2.35 is the fixed build of 8.2, not a new major version.

The CLI answer can be the wrong answer. On a typical hosting panel or a hand-built server there are several PHP binaries: one for cron and shell, one per FPM pool, sometimes a third inside a container. The site is served by whichever one the web server points at. If php -v says 8.3.36 and the site still behaves like an old build, you updated the wrong one.

If you do not have shell access

1. Hosting panel. cPanel → “Select PHP Version”; Plesk → “PHP Settings” per domain; ISPmanager and Hestia show the version per site. What matters is the version selected for that site, not the panel default.
2. WordPress. Tools → Site Health → Info → Server shows “PHP version”. It also reports whether an update is available.
3. Bitrix. Settings → Tools → “System check” (/bitrix/admin/site_checker.php) prints the PHP version, extensions and limits — and tells you if the version is below what the current kernel requires.
4. Ask the host, and ask for the number. “Latest PHP” is not an answer you can verify; “8.4.27” is.

Why the version matters more than usual this month

Two remote-code-execution bugs in PHP core — CVE-2026-109618 and CVE-2026-109619 — were fixed on 21 October 2026 in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. They need no account and no application logic: the malicious request is handled before your code runs, so logins, form validation and application firewalls are not in the path. The only complete fix is the updated build.

An end-of-life branch is worse than an unpatched one: there is no package to install. Which branches are still supported →