How to check your website's PHP version.

Most website owners have never needed to know which version of PHP their site runs on. After the PHP2Shell vulnerabilities were patched in October 2026, that number decides whether your site is exposed, whether a quick update fixes it, or whether you're looking at an upgrade project.

Below are five ways to find it, starting with the easiest. Pick the one that matches how your site is hosted. Then there's a table to read the number against, and what to do if your version turns out to be end of life.

1. WordPress Site Health

If your site runs WordPress, this is the quickest route and needs no technical access.

1. Log in to your WordPress dashboard as an administrator.
2. Go to Tools, then Site Health.
3. Click the Info tab and expand Server.
4. The line that says PHP version is the one you want.

WordPress will also show a warning on the dashboard and in the Site Health status tab if your PHP version is below what it recommends. Treat that warning as overdue, not optional.

2. cPanel or your hosting control panel

Most shared hosting uses cPanel or the host's own control panel.

• MultiPHP Manager (standard cPanel) lists each domain on your account and the PHP version it's set to.
• Select PHP Version (on hosts using CloudLinux) shows the current version and lets you switch.
• Plesk: go to Websites & Domains, choose the domain, then PHP Settings or PHP Version.

Check every domain on the account, not just the main one. Old microsites, staging copies and forgotten subdomains are often left on whatever version they were built with years ago, and an attacker only needs one way in to the account.

3. A phpinfo page

If you have file access (FTP or the hosting file manager) but no panel option, create a file in your site's root folder called something unguessable, such as check-8f3k2.php, containing one line:

<?php phpinfo();

Visit that file in your browser. The version is at the top of the page. Delete the file as soon as you've read it. A phpinfo page reveals a lot about your server's configuration and is exactly the kind of thing attackers scan for.

4. The command line

If you or your developer have SSH access to the server, php -v prints the version. Be careful with this one. The command-line PHP and the PHP serving your website are often different installs, especially on servers running several versions side by side. The phpinfo method above tells you what the web server actually uses.

On Linux distributions that backport security fixes (Ubuntu, Debian, Red Hat, AlmaLinux and others), the version number alone can mislead you. A distribution package might say 8.1 and still include the October 2026 fixes. Ubuntu 24.04's patched PHP package, for example, still reports itself as 8.3.6. To confirm, check the package changelog for the CVE numbers:

• Debian or Ubuntu: apt changelog php8.1-fpm | grep CVE-2026-10961 (swap in your package name)
• Red Hat family: rpm -q --changelog php-fpm | grep CVE-2026-10961

If both CVE-2026-109618 and CVE-2026-109619 appear, that package carries the fix. Restart PHP-FPM or your web server afterwards (a full restart, not a reload) so the running processes pick it up.

5. Your site's response headers

Some servers announce their PHP version in an X-Powered-By header. Your browser's developer tools (Network tab, click the page, look at Response Headers) or curl -sI https://yoursite.com will show it if it's there.

Most well-configured servers hide this header, which is good practice. So if you don't see it, that tells you nothing about whether you're safe. And if you do see it, it's worth asking your host to switch it off once you've patched.

Reading the number

The first two digits are the branch (8.3) and the last number is the patch level (.36). Patch updates within a branch are bug and security fixes only and rarely break anything. Moving between branches is where compatibility issues come in.

Do I need to upgrade my PHP?

Short answer: if your site is on PHP 8.1 or older, yes. Here's the full test.

• 8.1, 8.0, 7.4 or older: upgrade. These versions get no official security fixes, including for PHP2Shell.
• 8.2: update to 8.2.35 now, and plan an upgrade to 8.3 or 8.4 before 31 December 2026, when 8.2 support ends.
• 8.3, 8.4 or 8.5: no upgrade needed, but make sure you're on the latest patch release (8.3.36, 8.4.27 or 8.5.12 or newer).
• WordPress shows a "PHP Update Required" notice: your version is older than WordPress recommends. Treat it as a yes.

If you're on an end-of-life version

This is common. Plenty of sites are still on 7.4 because a plugin or theme needed it when the site was built, and nobody went back. You have three realistic options.

Ask your host about a backport. Some hosts and commercial support vendors maintain security patches for old PHP versions. If yours does, and confirms in writing that the October 2026 fixes are included, that buys you time. It's still borrowed time.

Upgrade to a supported version. This is the proper fix, and it's what my PHP upgrade service covers. I'd aim for 8.3 or 8.4 for most sites today. Skip 8.2 as a destination, since it goes end of life at the end of this year and you'd be doing this again in a few months. Go straight to 8.5 only if your theme and key plugins list support for it.

Rebuild, if the site is very old. If a site is on PHP 5.x or early 7.x and the theme or plugins are long abandoned, upgrading can cost more than replacing the parts that hold it back. That's a judgement call worth making with someone who has looked at the code.

How to upgrade without breaking things

1. Take a full backup of files and database, and confirm you can restore it.
2. Update WordPress core, themes and plugins first while still on the old PHP version. Many compatibility problems are already fixed in newer plugin releases.
3. Make a staging copy and switch that copy to the new PHP version. Most good hosts offer one-click staging.
4. Test the pages that make you money: contact forms, quote forms, cart, checkout, payment confirmation, account login. Check that form submissions still arrive and that conversion tracking still fires.
5. Watch the PHP error log on staging while you test. Deprecation warnings point you at plugins that need replacing soon.
6. Switch the live site at a quiet time, test the same pages again, and keep the backup to hand for a few days.

For an online store, step four matters most. A checkout that quietly fails after a PHP change costs more than the upgrade ever will, and it often shows up as a drop in sales before anyone spots an error.

The version number is a two-minute check. Not knowing it is how sites get caught.

Want me to check it for you?

If you'd rather not go digging, send me your web address through the free PHP2Shell website check. I'll confirm your PHP version, whether your host has patched it, and what the fix involves. If it needs an upgrade, you get a fixed quote and I do the work hands-on, including the staging and checkout testing above. I've worked on hundreds of websites across many hosting platforms and content management systems, including WordPress, WooCommerce and Joomla, so I know where upgrades tend to break and the checkout gets the most attention. WhatsApp or email me and I'll reply within one working day: rob@chiefgrowthengineer.com or +27 66 212 7955. This sits alongside the web development work I do for clients.

Filed under: Security · PHP · WordPress · Hosting · 2026