How to Check Whether Your Self-Hosted Apps Use a Vulnerable PHP Version

A host can run several PHP versions at once. The version returned by an SSH shell may belong to a command-line tool while a public website uses another runtime. To assess the October 2026 PHP vulnerabilities, tie every version result to an actual application and service.

Check the environment serving the application, not just the host’s command-line PHP. Compare the exact runtime branch or distribution package revision with the applicable advisory, allowing for documented vendor backports, and remove any temporary diagnostic page after the check.

1. Identify PHP-backed applications

List applications, installation methods, and external access routes. Check the application's documentation or package metadata to determine whether it uses PHP. Include side services such as cron runners and queues when they use the same application image.

Do not infer PHP usage from the NAS brand. A device running a mix of applications needs a per-service assessment.

2. Inspect a Compose deployment

docker compose ps
docker compose images
docker compose exec -T app php -v
docker compose exec -T app php --ini

Run these from the intended Compose project directory; replace app with the service that contains PHP. The commands identify the current containers and query the binary inside that service. If PHP runs in a separate php or fpm service, inspect that service instead.

A missing php executable is not proof that the application is safe. Minimal images, alternative binary paths, or separate runtime services may require the maintainer's inspection method. Do not install packages into a production container merely to complete a version check.

3. Inspect host-installed PHP

command -v php
php -v
php --ini

These describe the shell's PHP. Next, inspect your web-server configuration and service manager to identify the PHP-FPM pool, Apache module, or other handler serving the site. Check that component's package version and vendor advisory. PHP documents that configuration locations and behavior vary by server interface.

If a dashboard provides private runtime information for the actual web service, it can supplement the inventory. Do not leave a public phpinfo() page online; it can reveal details unrelated to the check.

4. Compare evidence against the advisory

For the October 21 incident, the upstream security releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. A later supported release in the same branch can include those fixes. If a distribution backports security patches, use its package revision and advisory rather than rejecting or approving a package by the upstream-looking number alone.

Record a result as one of three states: confirmed fixed, confirmed affected, or unresolved pending vendor evidence. For end-of-life software, establish a supported upgrade or an explicit maintained-vendor fix. An unresolved result should remain visible in your maintenance list.

5. Confirm what happens after the update

Repeat the same checks after deployment, including separate workers and containers. Record the image identifier or package revision and restart status. Test a normal authenticated request and the functions your household actually uses.

On a ZimaCube 2 personal cloud, keep this record with the app configuration and backup instructions. The useful outcome is a traceable statement such as “this application uses this patched runtime,” rather than “the NAS was updated.” If you find an affected container, use the linked update guide before changing its data volumes.

Explore ZimaCube 2 Personal Cloud Home NAS for your private storage and self-hosted application setup. Software security depends on the installed services, their configuration, and verified updates.

Sources and scope

Checked October 22, 2026. Deployment advice must be matched to your application and vendor documentation; these articles do not establish product-specific exposure.

• Docker Compose exec
• PHP runtime configuration
• PHP security release archive