How to check your exact PHP version in WordPress (and if it’s patched)
Short answer
In your WordPress admin, open Tools → Site Health → Info → Server. The line PHP version shows the full number, such as 8.3.36 (Supports 64bit values). For the October 2026 security release, what counts is the last part: your site is patched against CVE-2026-109618 and CVE-2026-109619 if it runs 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a later number in the same series. 8.1.x or older has no official fix at all. The PHP SAPI line just below tells you how your host runs PHP, which affects the level of risk.
Find the exact version
- In your WordPress admin, go to Tools → Site Health.
- Open the Info tab.
- Open the Server section.
- Read the line PHP version, and just below it PHP SAPI.
WordPress fills this line from PHP itself, the same value PHP reports while serving your pages (WordPress 7.1.2 source). That’s why it’s more reliable than a hosting panel, which may show only the series, or WP-CLI, which reports the command-line PHP (why that can differ).
Is it patched?
A PHP version has three parts: 8.3.36 is series 8.3, patch 36. The fixes of 21 October 2026 came in these patches (php.net):
| Your series | Patched from | Vulnerable |
|---|---|---|
| 8.5 | 8.5.12 | 8.5.11 and lower |
| 8.4 | 8.4.27 | 8.4.26 and lower |
| 8.3 | 8.3.36 | 8.3.35 and lower |
| 8.2 | 8.2.35 | 8.2.34 and lower |
| 8.1, 8.0, 7.4 | no official release | all |
The screenshot above, 8.5.11, is one patch short. One exception: some Linux distributions backport fixes into their own packages without changing the number. If Site Health shows a vulnerable number but your host says it’s patched, ask for confirmation in writing.
What the PHP SAPI line tells you
The SAPI is how PHP is connected to the web server. php.net lists the possible values of this setting, including apache2handler, cgi-fcgi, fpm-fcgi and litespeed (php.net). apache2handler means Apache with mod_php, the setup php.net considers most at risk for this release; fpm-fcgi means PHP-FPM. Both need the update: mod_php or PHP-FPM?
If it isn’t patched
- Hosted site: ask your host to update PHP (a message to send).
- Your own server: apply the update yourself.
- On 8.1 or older: upgrade WordPress from PHP 7.4, 8.0 or 8.1.
Everything else about PHP2Shell: what WordPress site owners should do now.
Key takeaways
- Tools → Site Health → Info → Server → PHP version: the full number, three parts.
- Patched: 8.2.35+, 8.3.36+, 8.4.27+, 8.5.12+. The first two parts tell the series, the third the patch.
- 8.1.x, 8.0.x and 7.4.x: no official fix, whatever the third number.
- The PHP SAPI line shows how PHP runs:
apache2handleris mod_php,fpm-fcgiis PHP-FPM. - WP-CLI and phpinfo files can show a different PHP than your website uses; trust Site Health.
Frequently asked questions
Site Health shows only 8.3. Where is the rest?
The Info tab shows the full version, for example 8.3.36. The Status tab’s PHP message shows the version in brackets as well. If you only see two parts, you’re reading a hosting panel, which often lists the series, not the patch.
My host says it runs 8.3 with security patches, but Site Health shows 8.3.35.
Some Linux distributions backport fixes without changing the version number. Ask your host whether their 8.3.35 package includes the fixes for CVE-2026-109618 and CVE-2026-109619.
Do I need to check after every PHP update?
It’s quick: open Site Health after your host announces an update, and compare the number.
Check your own site before you upgrade
CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.
Sources
- WordPress 7.1.2 source: Site Health Info (class-wp-debug-data.php)
- php.net: Security advisory, 21 October 2026
- php.net: php_sapi_name()
About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.