Since 21 October 2026 the question "which PHP version does my site run?" has become urgent. The two PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) sit in PHP itself, the runtime under WordPress, not in WordPress, a theme or a plugin. Updating WordPress changes nothing here. Only a patched PHP release does: 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a hosting vendor's package that explicitly contains the fix.
So the first step is simply to find out what you are running. There are four ways, from easiest to most technical.
1. WordPress Site Health
Log in to the WordPress dashboard and open Tools > Site Health. The Info tab has a Server section that lists the PHP version, the server architecture and the PHP SAPI (how the web server runs PHP). The Status tab also shows a warning when WordPress considers your PHP version outdated, but that check is about end-of-life branches in general, not about this specific advisory, so always read the exact number.
This is the version WordPress actually runs with, which is what matters.
2. Your hosting control panel
Most hosting accounts let you choose a PHP version per domain:
- cPanel: MultiPHP Manager, or Select PHP Version on CloudLinux servers.
- Plesk: Websites & Domains > PHP Settings (or the PHP tab of the domain).
- DirectAdmin: PHP Version Selector.
- Managed WordPress hosts: usually a PHP version or PHP engine setting in the site dashboard.
The panel shows the branch (8.3, for example) and often the full patch number. If it only shows the branch, use Site Health or a phpinfo page for the full number.
3. A temporary phpinfo page
Create a file named info.php containing:
<?php phpinfo();
Upload it to the site root and open https://yourdomain.com/info.php. The first line shows the exact PHP version, and the Server API row tells you whether the site runs under PHP-FPM, Apache mod_php, CGI or LiteSpeed. That detail matters: PHP's own advisory rates Apache mod_php as the highest-risk set-up.
Delete the file as soon as you have read it. A phpinfo page reveals a lot about your server and should never stay online.
4. On a VPS or your own server
If you manage the server yourself, keep in mind that the command line and the web server can run different PHP builds. php -v shows the command-line version only. For the version that serves your site, check the service that runs it, for example:
php-fpm8.3 -v # PHP-FPM
apachectl -M | grep php # Apache with mod_php
systemctl status php8.3-fpm
Or use the phpinfo page from step 3, which always reports the web-facing build.
Reading the number
Compare what you found with the fixed releases:
| Branch | Fixed release | Status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Supported |
| PHP 8.4 | 8.4.27 | Supported |
| PHP 8.3 | 8.3.36 | Security fixes only |
| PHP 8.2 | 8.2.35 | Security fixes only, ends 31 December 2026 |
| PHP 8.1 and older | none | End of life, no official release |
Anything below the fixed release in its branch is vulnerable. PHP 8.1, 8.0, 7.4 and older get no release from the PHP project at all; see our article on upgrading from end-of-life PHP.
One important exception: vendor packages
Linux distributions such as Ubuntu, Debian and Red Hat backport security fixes without changing the upstream version number. A fully patched Ubuntu 24.04 server can still report PHP 8.3.6, because that is the package version, and still be safe. The same applies to some hosting providers that build their own PHP packages.
If your number is below the fixed release but your server uses a distribution package, check whether the package changelog mentions CVE-2026-109618, for example with apt changelog php8.3-fpm on Ubuntu or Debian, or ask your hosting provider to confirm in writing that the patched package is installed and the PHP workers were restarted.
After the update
An updated package only takes effect once PHP has been restarted. Then:
- Open Site Health again and confirm the new version.
- Load the home page, a few inner pages, the login page and any forms or checkout.
- Check the PHP error log for new warnings. A patch release within the same branch rarely breaks anything; a jump across branches (7.4 to 8.3, for instance) can, which is why that deserves a planned upgrade rather than a quick switch.
When you cannot update yet
If the update has to wait for your hosting provider, PHP lists interim measures that reduce exposure: disabling session.upload_progress.enabled, sensible request-size limits and a web application firewall. They are not a fix. The patched release should follow as soon as it is available.
Need a second pair of eyes? Send us your website address and hosting provider and we confirm the version and what, if anything, needs to happen next.