How to Check Your PHP Version and Confirm PHP2Shell Is Patched

Your host says the server is patched. Your terminal says PHP 8.3.36. WordPress says something else. Which one is telling the truth? This guide shows you how to check your PHP version in WordPress and confirm the PHP2Shell fix is actually running.

Short answer: Go to Tools → Site Health → Info → Server in WordPress and read the PHP version line. PHP2Shell is fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later. After updating, restart every PHP-FPM service and the web server, because running processes keep the old code until they restart.

At a glance

• Who is affected: any WordPress site whose server runs a PHP version below the fixed release on its branch.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026.
• Check here first: Site Health in wp-admin, not php -v over SSH.
• Distro packages: search the package changelog for both CVE IDs, not just the version number.
• Do not skip: restart every PHP-serving process, then confirm the start times are after the update.
• On managed hosting: ask your host for written answers to four short questions.

Last reviewed: 8 November 2026 by Ali Shan, founder of WPRobo. We update this post when PHP publishes new fixes.

Some background first. PHP2Shell is the name for two flaws, CVE-2026-109618 and CVE-2026-109619. A CVE is a public ID number for a known security flaw. Both allow unauthenticated RCE (remote code execution): a stranger running their own code on your server.

The bug sits in PHP itself, not in WordPress. So any WordPress site on an unpatched server is exposed. For the full story, read our pillar guide, PHP2Shell: What WordPress and WooCommerce Owners Need to Do Now.

Which PHP versions fix PHP2Shell?

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all published on 21 October 2026. Anything below those numbers on its branch is affected.

• PHP 8.5: 8.5.12 or later
• PHP 8.4: 8.4.27 or later
• PHP 8.3: 8.3.36 or later
• PHP 8.2: 8.2.35 or later

The PHP security advisory of 21 October 2026 is blunt: “There are no complete mitigations, updating is the only safe choice.” Both flaws carry a CVSS v4.0 score of 9.2. CVSS is the standard 0–10 severity scale.

This is not theoretical. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026.

What about PHP 8.1 and older?

PHP 8.1 and older got no release from the PHP project. Its supported versions page shows 8.1 security support ended on 31 December 2025.

Some Linux distributions and LTS (long-term support) vendors ship their own backported fixes. If you are on 8.1 or older, the honest answer is an upgrade plan. Our guide to PHP 8.2 reaching end of life on 31 December 2026 walks through one.

How do I check my PHP version in WordPress?

Use Site Health. It reports the PHP that served the page you are looking at, which is the PHP an attacker would reach.

1. Log in to wp-admin.
2. Go to Tools → Site Health.
3. Open the Info tab.
4. Expand the Server section.

Read two lines. PHP version is the version that served that page. PHP SAPI tells you how PHP connects to the web server.

• fpm-fcgi: PHP-FPM, a separate pool of PHP worker processes the web server hands requests to.
• apache2handler: mod_php, where PHP runs inside the Apache web server itself.

Write the SAPI down. PHP rates the risk highest for mod_php, and the restart steps later depend on it. Rapid7’s analysis explains why the demonstrated attack on CVE-2026-109618 targets mod_php.

No wp-admin or SSH? Use a temporary phpinfo() file

A phpinfo() page shows the version and Server API. It also exposes a lot of server detail you do not want public. Treat it like an open window.

<?php
// Save as e.g. info-7f3k9q2x.php in the web root. Delete immediately after reading.
phpinfo();

1. Give the file a random name nobody will guess.
2. Load it once. Note PHP Version and Server API.
3. Delete it straight away. Forgotten phpinfo() files are a gift to anyone scanning for them.

Why does SSH show a different PHP version?

Because php -v reports the command-line (CLI) PHP, not the PHP your website runs on. They can be different versions, packages or branches.

This is where most people get a false answer. You SSH in, see a patched version and relax.

php -v
wp --info

Both commands report the CLI binary. WP-CLI runs on it too. Your site runs on PHP-FPM or mod_php instead.

Older servers often carry several PHP versions side by side. The CLI might point at 8.4 while the site’s FPM pool still runs 8.2. Updating one does not touch the other.

List the PHP versions installed

On Debian and Ubuntu, each version has its own directory and FPM binary:

ls /etc/php/
ls /usr/sbin/php-fpm*
dpkg -l | grep -E '^ii\s+php[0-9.]*-(fpm|cli|common)'

On RHEL, AlmaLinux and Rocky, there is usually one system PHP, sometimes with extras from software collections:

rpm -qa | grep -E '^php.*(fpm|cli|common)'

Check each FPM binary directly

# Debian / Ubuntu
php-fpm8.3 -v
php-fpm8.2 -v

# RHEL family
php-fpm -v

Find which PHP your site actually uses

Knowing what is installed is half the job. You also need the pool your site hands requests to.

On nginx, find the fastcgi_pass socket:

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/

A line like unix:/run/php/php8.3-fpm.sock means the site uses the 8.3 pool. On Apache with FPM, search for the proxy handler:

grep -R "proxy:unix" /etc/apache2/ /etc/httpd/ 2>/dev/null

To check for mod_php, list the loaded Apache modules:

apache2ctl -M | grep -i php   # Debian / Ubuntu
httpd -M | grep -i php        # RHEL family

Then see what is running right now. The FPM master process names its config file, which gives away the version:

ps aux | grep "php-fpm: master"

How do I check a distro package for the fix?

Search the package changelog for both CVE IDs. A distro version number alone proves nothing either way.

Debian, Ubuntu and RHEL often backport a security fix without moving to the upstream version number. Your package might report an older 8.x version and still contain the fix.

On Debian and Ubuntu:

apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]"

# Or read the changelog shipped with the installed package
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -E "CVE-2026-10961[89]"

On the RHEL family:

rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"

Swap in the package name your site uses. If both CVE IDs appear, the installed package carries the fix.

If nothing appears, do not assume the worst or the best. Check your distribution’s security tracker or ask the package maintainer.

Do I need to restart PHP after updating?

Yes. Installing a patched package does not patch PHP processes that are already running. A worker started last week still runs last week’s code until it restarts.

Tenable’s PHP2Shell FAQ repeats Google Cloud’s guidance on this point. PHP-FPM, Apache and any other PHP-serving process must be restarted.

This step gets skipped more than any other. The package manager reports success, and everyone moves on.

Step 1: install the updates

# Debian / Ubuntu
sudo apt update
sudo apt upgrade

# RHEL family
sudo dnf upgrade 'php*'

Step 2: restart PHP and the web server

Restart every PHP-FPM service, not just the one you think the site uses. Then restart Apache if it is in the picture.

# Debian / Ubuntu: one line per installed FPM version
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm
sudo systemctl restart apache2

# RHEL family
sudo systemctl restart php-fpm
sudo systemctl restart httpd

• PHP-FPM: restart each FPM service. A full restart leaves no doubt about which binary is loaded.
• mod_php: restarting Apache is the step that matters.
• LiteSpeed: restart the server and confirm no old lsphp processes are left behind.

Step 3: verify the new processes

Do not trust the restart command’s silence. Check that the running processes started after the update.

# When did each FPM master start?
ps -o pid,lstart,cmd -C php-fpm8.3

# Or read the service status
systemctl status php8.3-fpm | grep Active

Compare that time with the install log:

grep "php8.3-fpm" /var/log/dpkg.log | tail -n 5    # Debian / Ubuntu
rpm -q --last php-fpm                                # RHEL family

Then reopen Tools → Site Health → Info → Server. It should read 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later. With a backported distro package, the changelog check is your confirmation instead.

Finally, click through the site. Load the home page, a product, the cart, checkout and the admin. A fatal error is far better found by you than by a customer.

Watch for the SimpleXML regression

PHP 8.4.27 and 8.5.12 shipped with a SimpleXML crash regression (php-src issue #24488). It is unrelated to the security fixes. If XML parsing starts failing after the upgrade, look there first.

Do not roll back to a vulnerable version. Test XML-dependent features, such as feed imports or custom integrations, and work around the crash instead.

What should I ask my host?

Ask for the exact PHP version serving your site and confirmation that every worker was restarted. Get the answers in writing.

On managed WordPress hosting, you probably have no root SSH access. You still have every right to a clear answer. “We handle security” does not automatically cover this patch.

1. Which exact PHP version serves my site right now? If it is a backported package, does it include fixes for CVE-2026-109618 and CVE-2026-109619?
2. Were all PHP workers and web server processes restarted after the update? When?
3. Is my site served by PHP-FPM, mod_php, LiteSpeed or something else?
4. Have you set session.upload_progress.enabled=0 while CVE-2026-115560 remains unfixed?

Then check Site Health yourself and compare. A good host answers all four without fuss. A vague reply is useful information too.

The last question covers a separate advisory from 23 October, which the 21 October releases do not fix. Our guide to turning off PHP session upload progress safely explains what to change and where. The PHP session configuration manual documents the setting itself.

How we handle this on client sites

We treat a PHP security patch as finished only when the patched code is running and verified. Here is what that looks like in practice.

• We check the PHP version the web server reports in Site Health, not the SSH one.
• We record the SAPI, because mod_php and PHP-FPM need different restart steps.
• We map every installed PHP version and the pool each site actually uses.
• For distro packages, we confirm the CVE IDs in the changelog rather than trusting the version string.
• We restart every PHP worker and compare process start times with the install log.
• We click through checkout and the admin before calling the job done.
• We write down what was changed, when and what we verified.

If you would rather hand the whole job over, our WordPress maintenance and support service covers exactly this work.

What does this check not tell you?

A patched, restarted PHP closes the two PHP2Shell flaws on that server. It does not tell you whether anything happened before you patched.

Tenable reports that Amazon’s threat intelligence team saw an exploitation attempt on honeypots on 17 October 2026. That was four days before disclosure. Broad attempts in the wild followed.

If your server ran an affected version on the open internet, review it. Look for unexpected PHP files, unknown admin users and changed core files. Our WordPress security checklist covers those checks step by step.

Keep your PHP branch supported, too. The WordPress.org requirements page lists the PHP versions WordPress recommends. Patching this flaw reduces risk today. It does not replace staying on a supported, updated branch.