How to Check Your PHP Version After PHP2Shell

Running php -v and seeing a version number is not enough to know whether a server is safe from PHP2Shell. Linux distributions and hosting panels often ship the fix without changing the version string, so a server that says 8.1.34 can be patched while one that says 8.4.26 is not. This guide shows how to check your PHP version properly on WordPress, a control panel, a Linux server and Docker, and how to confirm the fix is really there.

PHP2Shell is the name for two critical PHP engine flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For what the flaws are and how to patch them, read the full PHP2Shell explainer. This post is about the step before and after patching: finding out what you actually run.

Why checking your PHP version is trickier than it looks

Three things catch people out, and I've hit all of them on client servers.

• Backports keep the old version number. Debian, Ubuntu, RHEL-family distributions and cPanel's EasyApache all backport security fixes into older branches. The package is patched, the version string still looks old.
• The command line and the website can run different PHP. php -v reports the CLI binary. Your site may be served by PHP-FPM or Apache with a different version, especially on servers with several PHP versions installed side by side.
• A control panel switcher doesn't install anything. Choosing a newer PHP in a hosting dashboard points your site at an already-installed version. If the host hasn't patched that version yet, you've changed the number, not the exposure.

My rule: trust the package changelog over the version string, and trust what the web server reports over what your terminal reports.

How to check your PHP version

From the command line

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'
php-fpm -v                 # or php-fpm8.4 -v on Debian and Ubuntu
apachectl -M | grep php    # shows mod_php if it's loaded

In a Laravel project

php artisan about

In WordPress

Go to Tools → Site Health → Info, open the Server section and read PHP version. Hosting dashboards usually show it too, but remember that's the selected version, not proof the fix is installed.

From a PHP file on the web server

This reports what the web server really runs, which is the version that matters.

<?php echo PHP_VERSION;

Upload it, load it in a browser, then delete it. Don't leave a phpinfo() page on a public site, because it hands attackers your full server configuration.

Is that version patched? Compare against the fixed releases

| PHP branch | Patched from | |---|---| | 8.5 | 8.5.12 | | 8.4 | 8.4.27 | | 8.3 | 8.3.36 | | 8.2 | 8.2.35 |

If you're on one of these or newer, you're patched. If you're on 8.1 or older, the PHP project doesn't release fixes, so you need either a vendor backport or a move to a supported branch. If your number is lower than the table on a supported branch, you're vulnerable unless your vendor backported the fix, and that's exactly what the next section checks.

Confirm the fix by looking for the CVE IDs

When the version looks old, ask the package itself. The patched builds list both CVE IDs in their changelog.

Debian and Ubuntu

dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'
apt changelog php8.4-fpm | grep -E "CVE-2026-10961[89]"

RHEL, AlmaLinux and Rocky

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

Alpine

apk info -v | grep '^php8'

On Alpine the fixed packages are php83 8.3.36-r0, php84 8.4.27-r0 and php85 8.5.12-r0 or newer, and older Alpine releases may not have an update yet, so check the vendor's advisory.

cPanel and EasyApache

rpm -qa 'ea-php*-php-cli' | sort
rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618

Upstream branches show up as a version bump (ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36, ea-php82 8.2.35). The backported older branches, ea-php81, ea-php80 and ea-php74, keep their old version strings and show the fix as a changelog line that names the EasyApache case. Empty output from the grep means that package is still vulnerable. cPanel's own PHP is separate again, so update it too (/scripts/upcp).

Docker

Official image tags 8.5.12-*, 8.4.27-*, 8.3.36-* and 8.2.35-* carry the fix, for example php:8.4.27-fpm. Pulling a tag doesn't patch the container you already run. Rebuild, redeploy, then confirm inside the running container:

docker exec <container> php -v

Check the base image tag in your Dockerfile too, because a pinned old tag will quietly rebuild the vulnerable version.

As these details are changing fast, treat package versions as of 22 October 2026 and confirm them against your vendor's own advisory.

Using WordPress or shared hosting? Ask your host the right question

You can't patch PHP on shared or managed hosting yourself, so the check is a conversation. According to Meow Apps' WordPress guidance, WordPress updates, plugins and firewall plugins don't fix this, because the fix has to be installed in PHP on the server.

Send your host this:

Has PHP on my server been patched for CVE-2026-109618 and CVE-2026-109619? Please confirm that the fix is installed, not only that a firewall rule is in place, and tell me which PHP version my site is running.

Read the answer carefully. "We've added firewall protection" and "PHP is updated" are different statements. A firewall rule can reduce attack traffic, but only a patched PHP removes the flaw. If you're on PHP 8.1 or older, back up the site, update your plugins and themes, and move to 8.3 or 8.4, then test your key pages.

What to do if the check fails

1. Update PHP to a fixed build, or ask your host to.
2. Restart every PHP worker. For PHP-FPM or Apache that means a restart, not a reload of one pool.
3. Run the same check again. A package upgrade without a restart leaves the old code in memory.
4. If you can't patch yet, apply the temporary settings from the main explainer, knowing they're a partial stopgap.

Signs a WordPress site was compromised

Patching closes the door, it doesn't tell you whether anyone came in first. Check for unknown administrator accounts, plugins you didn't install, .php files inside wp-content/uploads, odd pages showing up in Google for site:yourdomain.com, and malware or resource warnings from your host. If you find any, ask the host to scan the server, restore a clean backup and change every WordPress, hosting and database password.

Frequently Asked Questions

My php -v shows 8.2.34. Am I vulnerable? Against upstream PHP, yes, since 8.2.35 is the fixed release. If the build came from a distribution or a panel such as cPanel, it may still be patched, so look for the CVE IDs in the package changelog.

Does changing the PHP version in cPanel patch the server? No. It switches which installed PHP version your site uses. The version you switch to still has to be patched on the server by your host.

Can I check my site from the outside without server access? There's no reliable way to confirm it from outside. Some public checkers exist, but they only infer exposure, and a version header can be hidden. The dependable checks are the ones above, run on the server or confirmed by your host.

Do I need to restart anything after updating? Yes. Restart PHP-FPM or Apache so every worker loads the fixed code, then re-run the version and changelog check.

Key Takeaway

Check three things in order: the version your web server really runs, the package changelog for CVE-2026-109618 and CVE-2026-109619, and whether the workers were restarted after the update. If you're on shared hosting, get the host to confirm in writing that PHP itself is patched.

Last checked 22 October 2026. Sources: PHP advisory GHSA-w8hw-w9fx-j79w, Meow Apps WordPress guide, Computing for Geeks cPanel patch steps and Digital Applied distro summary.