How to Check Whether a PHP Security Update Has Been Applied

The short answer

Ask whoever runs your server to confirm, in writing, which PHP build serves your site, that it includes the fix, and that PHP workers were restarted. If you run the server yourself, check the installed package against your vendor’s advisory, check which build the web server actually uses, and restart it. The rest of this guide explains why each of those steps matters. For background on the current advisory, see the October 2026 PHP security release.

Who is responsible for patching PHP on your site?

Usually your hosting company. PHP is part of the hosting environment, so whoever controls that environment patches it:

• Shared or managed hosting (for example a WordPress host): the host installs and patches PHP. You may be able to choose a version in the control panel, but the host supplies the builds.
• A VPS or dedicated server: whoever administers the server patches PHP, which may be you, your developer or a managed-service provider.
• A platform service such as AWS Elastic Beanstalk or a container image: the platform or your build pipeline decides the PHP build.

To find the host, look for the company you pay for hosting on a card statement or in your email. Your domain registrar is often a different company. Your hosting control panel usually has a PHP version or PHP settings screen. It shows the branch your site is set to use, which helps, but it does not usually show whether a security fix is in the build.

What each kind of evidence proves

Each way of checking answers a narrower question than it seems to:

Can an outside scan show whether PHP is patched?

No. Some servers announce their PHP version in an X-Powered-By response header, and some online tools read it. That header is optional and commonly turned off. When it is present, it shows a version string, not the vendor’s patch level. Content delivery networks and proxies can remove or change headers along the way. So a missing header does not mean a site is safe, an old-looking number does not mean it is vulnerable, and nothing visible from outside can settle the question. Please do not run attack tools against a site to find out; testing exploits against live systems can cause damage and is not a verification method.

Why can a patched PHP show an old version number?

Because Linux and control-panel vendors usually fix the version they already ship instead of moving to a new one. Hosts rarely run PHP built from php.net source. They install packages from the operating system vendor, a control-panel vendor or a specialist repository. Those vendors often apply the security fix to the version they already ship, so the package keeps its older main version number with a new build suffix:

The authoritative check is the installed package’s exact version compared with the fixed version in that vendor’s own advisory, such as the Ubuntu or Debian security tracker pages. For cPanel, Plesk, CloudLinux and similar builds, the control-panel vendor’s release notes are the reference.

Is command-line PHP the same as the website’s PHP?

Not necessarily. A single server can have several PHP builds installed side by side, and different sites on the same server can use different ones. The command php -v reports the command-line binary on the system path, which may not be the build your web server uses. What matters for a website is the PHP that handles web requests. PHP calls the connection between PHP and the web server the server API (SAPI), for example FPM or the Apache module; the PHP manual describes how to read it.

An administrator can see the web runtime’s version and SAPI on the PHP information page, served briefly through the site and removed straight after, because it exposes configuration details. Many control panels show the same information without that risk. On WordPress, Site Health shows the PHP version the site runs under (WordPress documentation); see does updating WordPress update PHP? for what it does and does not tell you.

Does installing the update protect the site straight away?

Not until PHP is restarted. PHP-FPM pools, Apache with the PHP module and similar setups keep worker processes running between requests. Those processes keep using the code they started with until they are restarted or reloaded. PHP’s advisory pairs every interim setting with “restart every worker” for this reason. A server can have the fixed package installed and still be serving requests from the old build.

What confirmation should you ask your host for?

Send something like this to your host or administrator. Never include a password.

A clear answer to all four points is good evidence that the patch is in place. It does not cover whether the site was attacked before the update; if anything looked unusual, read patching is not an investigation.

Common questions