Check three things: which PHP runtime serves your site, who distributes or manages it, and whether the relevant fix has reached that runtime. Running php -v in a terminal does not by itself establish the Web runtime's status. Start with the environment that you actually manage below.
Official documentation checked on 26 October 2026. This guide covers checking methods. Use the specific advisory and your distributor's official notice for affected conditions, fixed versions and mitigations. The commands here display version or configuration-file information; they do not update or restart services.
1. Choose the environment you manage
- ▸Shared or managed hosting: check the target domain's control panel and your provider's notices. Do not follow instructions for replacing an operating system's PHP yourself.
- ▸A server you administer: distinguish CLI and Web runtimes and record the OS, package and distributor.
- ▸Docker: check the running container that actually supplies PHP to the site, not just the host.
- ▸No administrator access or an unknown setup: send the enquiry checklist below to the administrator or provider. Our recommendation is to avoid changing production settings when the setup is unclear.
2. Hosting: check the selected version and provider's response
- ✓Identify the domain and hosting plan, then open that site's PHP settings. Separate the available versions from the version currently selected.
- ✓Read the provider's security and maintenance notices for the affected service, the relevant vulnerability, rollout time or completion time, and any action required from you.
- ✓If the panel shows only a branch such as 8.x, do not infer patch status from that label. Ask the provider for confirmation.
If you use Smile Server in Japan
Smile Server's V5 documentation from 2021 describes the Site Manager path WEB & FTP management, CGI management, then PHP version switching. This is an old V5-specific instruction, not a statement that every current plan uses the same screen. Consult the manual for your contract and ask support if the screen differs. That notice alone does not establish today's available versions or the status of any particular security fix.
3. Your own server: separate CLI and Web PHP
An administrator with shell access can start with these two commands. The PHP manual documents -v as showing the version and SAPI (execution interface), and --ini as showing configuration-file names and scanned directories. An output marked (cli) describes CLI PHP. Do not assume that the site's PHP-FPM or Apache PHP has the same version or configuration.
php -v
php --iniIn the illustrative output PHP 8.x.y (cli), 8.x.y is the version and cli is the interface. It is a notation example, not a real fixed release. A command-not-found error means that PHP could not be checked from that shell; it does not establish that the website has no PHP runtime.
For Web PHP, use an existing authenticated administration or diagnostic screen if one is available. Otherwise ask the administrator to obtain phpversion() and php_sapi_name() from the runtime processing requests for that site, through a controlled method. They return the running PHP version and interface respectively. phpinfo() exposes configuration and environment details as well, so our recommendation is not to create or leave a publicly accessible diagnostic page.
4. Docker: check the running application container
This example is for a Docker administrator. Replace PHP_CONTAINER with the existing name or ID of the container supplying PHP to the site. Docker's exec runs a command in a running container. The example requires an available php executable inside that container.
docker exec PHP_CONTAINER php -vThis again checks CLI PHP. If it fails because php is unavailable, the container is stopped, or another prerequisite is missing, ask the administrator to identify the relevant runtime. Our checking policy is to match the actual running environment to its distributor's fix information, rather than treating the host's version or an image tag as proof of completion. Check Web PHP as in the previous section. Follow the administrator's or distributor's process for actual updates and container recreation.
5. Match what you found to the distributor's fix information
Upstream PHP support status and remediation of a particular vulnerability are separate checks. Ubuntu, for example, delivers security fixes as backported patches to existing release series. Do not decide whether an OS package is fixed solely from the upstream PHP version number. Nor should Ubuntu's policy be assumed to describe every distributor.
- ✓Identify the vulnerability being checked and open your distributor's official advisory.
- ✓Match your OS, hosting service, distributor and complete installed package version to the notice's scope.
- ✓If an update is needed, use the official procedure for that environment. Confirm any required restart or process replacement is complete.
- ✓Check the same site and runtime again afterwards, recording the time and the supporting notice.
- ✓If the fix cannot be established, record the result as unconfirmed and ask the administrator or distributor. An unknown version is not evidence that the environment is unaffected.
What to ask an administrator or hosting provider
This is our enquiry checklist. Send contract and domain details only through the official support channel. Do not attach passwords, tokens or entire configuration files.
- ▸The target domain, hosting plan and time of your check.
- ▸The vulnerability identifier or official advisory URL you want checked.
- ▸The actual Web PHP version, execution interface and distributor for the site.
- ▸Whether the fix is applied, the supporting package version or notice, and its deployment time.
- ▸Whether you need to select another version, restart anything, or perform another action.
