How to Check PHP Version and Know If Your Site Is Patched (October 2026)

To check your PHP version in WordPress, log in as an administrator, go to Tools, then Site Health, click the Info tab and open the Server section: the "PHP version" line shows the full release number, such as 8.3.36. WordPress adds "(Supports 64bit values)" after it, which you can ignore.

Read the PHP SAPI line too, which most guides skip. It says how PHP is plugged into your web server. apache2handler means PHP runs inside Apache as mod_php, the setup the PHP project rates as the highest risk, with "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs". fpm-fcgi (PHP-FPM) and litespeed are the other common answers. The PHP security advisory lists all of them as affected, so this line tells you how urgent your case is, not whether you're safe.

One caution: the "Copy site info to clipboard" button on that screen copies your whole configuration, so only paste it to someone you trust. WordPress's documentation explains the rest of the screen.

WordPress doesn't warn you about PHP2Shell because its PHP check compares your branch against a recommended version, currently 8.3, and never looks at the patch level. On a site running 8.3.35, the release just before the fix, Site Health shows a green "Your site is running a recommended version of PHP".

The check asks a WordPress.org service called Serve Happy about your version and caches the answer for a week. I asked it about a few versions on 23 October. It called 8.3.35 secure. It also called 8.1.34 secure, though PHP stopped supporting 8.1 on 31 December 2025 and released no fix for it this week.

That isn't a bug in WordPress so much as a label that means less than it sounds. A comment in WordPress's own Site Health code says it plainly: "The is_secure array key name doesn't actually imply this is a secure version of PHP. It only means it receives security updates."

So a quiet dashboard tells you nothing about this week. You need the number itself, read against the table further down.

Every hosting control panel shows the PHP version a site uses, but most of them show only the branch, such as 8.3, and not the exact release, so a panel alone usually can't tell you if you're patched. Here's where to look on the panels Singapore businesses use most.

Only Hostinger's PHP Info page gives you the exact release inside the panel, and it's really a phpinfo page Hostinger hosts for you. Everywhere else, the label names the branch you picked, because a branch is all a panel lets you pick. In cPanel, "inherit" means the domain follows a server default that, per cPanel's documentation, only the server administrator can set.

To switch the branch while you're in there, my guide to changing PHP version in cPanel and other hosts has the click paths and how to switch back if the site breaks.

No. "PHP 8.3" in a hosting panel is a branch that covers every release from 8.3.0 to 8.3.36, and only 8.3.36 carries the PHP2Shell fix. Choosing 8.3 in a dropdown picks the branch. Installing the patched release on the server is your host's job, or whoever runs your server.

The numbers move fast. PHP's security release of 24 September put well-kept servers on 8.3.35. Four weeks later, PHP's own 8.3.35 is the vulnerable one.

And there's a twist the other way. Linux distributions and CloudLinux, which sits under a lot of cPanel shared hosting, often patch their own PHP packages without changing the version number. So a lower number isn't always bad news:

• CloudLinux's patched build of cPanel's PHP 8.3 package is version 8.3.35-2, so a site on it reports 8.3.35. CloudLinux says: "Our packages carry the fix as a backport, so their version numbers stay below PHP's."
• Ubuntu 24.04's fixed package is 8.3.6-0ubuntu0.24.04.13 (USN-8948-1, 21 October), so the version still starts with 8.3.6.
• GoDaddy told its Web Hosting customers on 22 October that "your PHP version number may not change after this update", and to check that the PHP build date is 21 October 2026 or later instead.

So here's the rule. A number at or above the fixed release is patched. A number below it is unpatched if it's PHP's own build, and may be patched if your host uses a distribution or CloudLinux package. Only the host can say which, and the message further down asks them.

A phpinfo file is a one-line PHP script you upload to your site; opening it in a browser shows the exact PHP version your website runs, plus the Server API, on one page. It's the most reliable check, because it asks the same PHP that serves your pages. It's also the one you must clean up after.

1. Open your host's File Manager, or connect by SFTP, and go to the folder your site lives in. On cPanel that's usually public_html.
2. Create a new file with a name nobody would guess, like check-7f3k2.php. Don't call it phpinfo.php or info.php: bots request those names all day.
3. Put this one line in it: <?php phpinfo();
4. Open https://yourdomain.sg/check-7f3k2.php. The version is in the heading at the top, for example "PHP Version 8.3.36".
5. Look for the Server API row a few lines down. "Apache 2.0 Handler" means mod_php, "FPM/FastCGI" means PHP-FPM, and "LiteSpeed" means LiteSpeed.
6. Delete the file straight away.

Also read the Build Date line. GoDaddy and Hostinger both tell customers that a build date of 21 October 2026 or later means the fix is in on their servers, because a backported fix doesn't change the number but does change the date.

Why delete it? The PHP manual lists what phpinfo() prints: server and OS details, file paths, every configuration value, HTTP headers and the environment, which on some setups holds database passwords or API keys. A forgotten phpinfo file does an attacker's homework for them.

On Hostinger, skip the upload: hPanel has a built-in PHP Info page that shows the same output.

You can check a website's PHP version from the browser only if its server sends an X-Powered-By response header, which reads something like "PHP/8.3.36"; the header can be switched off, so a missing one proves nothing. To look in Chrome or Edge:

1. Open your site and press F12 (Cmd, Option and I on a Mac).
2. Click the Network tab and reload the page.
3. Click the first row, which is your page itself, and open Headers.
4. Under Response Headers, look for x-powered-by.

From a terminal, curl -I https://yourdomain.sg prints the same headers.

PHP sends the header when its expose_php setting is on, which the PHP manual gives as the default. Hosts can turn it off, and Wiz's PHP2Shell page suggests it as "optional hardening" that "does not remediate PHP2Shell". A CDN in front of your site can strip headers too. And when the header is there, the backport caveat above still applies.

Online "what PHP version is this site" checkers read the same header. When it's hidden, they can only spot clues like a PHPSESSID cookie, which says PHP is there but not which release. That's why I don't trust an outside scan to clear a site for this bug, as I explain in my roundup of free website security check tools.

Running php -v over SSH prints a PHP version, but it's the command-line PHP, which on most hosting servers is not the one serving your website. Your site may use any of the other PHP binaries on the server.

If you or your developer have SSH access, these get closer to the truth:

• cPanel servers: /opt/cpanel/ea-php83/root/usr/bin/php -v checks the 8.3 your sites use (swap 83 for your branch). On CloudLinux, where the number can sit below the fix, CloudLinux tells admins to search the package changelog instead: rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'. If the CVE numbers come back, the fix is in.
• Ubuntu, Debian, AlmaLinux, Rocky, Red Hat: apt policy php8.3-fpm or rpm -q php-common shows the package version, which you compare with your distribution's security notice, not with 8.3.36. AlmaLinux's notice puts it bluntly: "Don't rely on php -v".

One more trap: php -v can show the new release while the website still runs the old one, because PHP-FPM or Apache keeps the old code in memory until it's restarted. The PHP advisory says to "restart every worker" for the same reason, and it's why I trust a phpinfo page over the terminal.

The PHP versions patched against PHP2Shell are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later on each branch; older releases on those branches are vulnerable unless your host's package carries a backported fix, and 8.1 or older has no release from the PHP project. The number settles it for PHP's own builds and for what most host panels show. For a Linux distribution or CloudLinux build, the real answer is in the host's changelog. Find your number in the left column.

Dates come from PHP's supported versions page and end-of-life list. PHP's security team also published minimal source backports for 7.4 to 8.1, but those help people who compile PHP themselves, not shared hosting customers. Tenable's FAQ traces the vulnerable code back to PHP 5.4.0.

8.2 stops getting security fixes on 31 December 2026, ten weeks from now, so 8.2.35 is a stopgap. If you're on 8.2 or older, my guide to PHP end of life and the supported versions explains what an unsupported branch means in practice.

What you do next depends on which row of the table you're in: patched sites need nothing for this bug, sites on an old release of a supported branch need the host to install the update, and sites on 8.1 or older need to move to a supported branch.

• Patched (8.3.36, 8.4.27 and so on). You're done for PHP2Shell. Check your other sites and subdomains too, since each can run its own version.
• Supported branch, older release (8.4.26, 8.3.35 and so on). It may be unpatched, or a backported build. On shared hosting, that's your host's job, and re-picking the branch in the panel won't help. Send them the message below. On a VPS or cloud server, someone on your side has to update and restart PHP.
• 8.1 or older. There's no upstream fix to wait for. Moving a WordPress site up a branch can break plugins and themes, so do it on a copy first. My guide to updating PHP in WordPress without breaking it has the backup, staging and testing steps.

If you can't tell, ask. Copy this into an email or your host's support chat:

Hi, my website is yourdomain.sg.
1. Which exact PHP version does it run? Please give the full number, e.g. 8.3.36, not just 8.3.
2. Is that PHP fixed for CVE-2026-109618 and CVE-2026-109619 (the PHP security releases of 21 October 2026)? If the number is lower because your package carries a backported fix, please confirm that.
3. Has PHP been restarted on my server since the fix went in?

If you'd rather not deal with any of it, start with my free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, and tell you what I find, free. If your host has already patched it, I'll say so and you won't need me. If it needs the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850, through my website maintenance service. To keep PHP, plugins and backups current after that, the content retainer is SGD 550 a month for updates, backups, security and 5 hours of changes, month to month.

No. Wix, Squarespace, Shopify and Webflow are hosted platforms where you never see or choose a PHP version, and keeping their servers patched is the platform's job, not yours. There's nothing for you to check or update for PHP2Shell on those sites.

The catch is what sits beside them. An old WordPress blog at blog.yourdomain.sg, or a booking system a vendor set up on a subdomain in 2019, is a PHP site. CISA told organisations on 21 October to inventory every system running PHP, because "PHP is often a component of other software", and Singapore's CSA asked them to check where third-party applications use it too.

Not necessarily. Panels like cPanel let each domain and subdomain run its own PHP version, so one hosting account can have a patched main site and an unpatched microsite side by side. Check each one, not just the homepage.

The ones I find most often are a forgotten staging copy and a second WordPress install in a folder like /old, and the forgotten ones are usually on the oldest PHP.

Check your PHP version every time PHP announces a security release, which happened five times between May and October 2026, and at least once a quarter otherwise. Each check takes two minutes with the methods above.

Also check after a plan change or a server move, because the new server isn't always on the same release as the old one.