Why php -v Is Not Enough: Verify PHP-FPM, Apache and Web Requests

What the shell command really establishes

php -v reports the executable resolved in that shell. A service account, cron job, deployment script or explicit binary path can resolve something different. Use read-only discovery before changing configuration:

command -v php
php -v
php --ini

Record those results as CLI evidence. Do not label them web-runtime evidence. PHP documents configuration-file selection, including the possibility of SAPI-specific configuration files. Updating a package and changing a loaded configuration are related operations, but they are not interchangeable observations.

For an illustrative server, the login shell might use one package's binary while a website forwards requests to a separately installed FPM service. This is an example of a topology to investigate, not a claim that your host uses those paths.

Trace the web request to its interpreter

Ask which virtual host answers the domain, whether a proxy forwards dynamic requests, which socket or service it selects and which executable runs that service. For Apache, distinguish an embedded module from a FastCGI/FPM integration. For a managed platform, request this mapping from the provider rather than assuming you can inspect its private service configuration.

The PHP-FPM documentation describes separate global and pool configuration. When several pools or services exist, verify the one reached by the relevant website. Changing a similarly named unused pool does not demonstrate anything about production traffic.

Write the path as a sentence: “This hostname reaches this virtual host, which dispatches dynamic requests to this PHP service.” Attach the evidence for each link. The sentence is deliberately more useful than a directory full of unrelated diagnostic screenshots.

Get a minimal observation from the web execution context

PHP provides phpversion and php_sapi_name to report runtime identity and interface information. Prefer an existing authorised application diagnostic. If a custom diagnostic is necessary, place it only behind an existing trusted administrator/access-control boundary.

A minimal diagnostic body, to run inside that protected environment, is:

<?php
// Run only inside an existing authenticated diagnostic route.
header('Cache-Control: no-store');
header('Content-Type: application/json');
echo json_encode([
    'version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
], JSON_THROW_ON_ERROR);

This is not a complete authentication handler and must not be exposed as a standalone public file. It intentionally avoids dumping environment variables, credentials and filesystem paths. Remove any temporary route after collecting the necessary evidence.

Verify the restart or replacement, not only the package installation

When PHP runs in persistent web processes, an on-disk package result is not the whole deployment record. Ask how the relevant service replaces its workers, whether old processes can remain and how the rollout is verified. Use the procedure appropriate to the host rather than copying a restart command with a guessed service name.

A graceful reload and an immediate restart can have different availability implications. The person responsible for the service should choose the operation based on the security advisory, process model and traffic requirements. A WordPress administrator on shared hosting generally needs provider confirmation rather than permission to restart the shared service.

Afterward, collect a fresh authorised web observation. Where a load balancer or sticky session is involved, one successful request may represent only one worker group. Use deployment/orchestrator evidence or a controlled diagnostic strategy that identifies each member without exposing internal infrastructure publicly.

Add cron, workers and images to the evidence table

Scheduled jobs may contain a hard-coded PHP path. Queue processes may remain alive across a deployment. Containers may use a base image that was current when built but has not been rebuilt since a security update.

Use one evidence row per execution context: web, CLI, queue worker, scheduled job and image revision where applicable. Record the responsible owner and whether that context is reachable from untrusted input. This keeps an urgent web-runtime fix from accidentally becoming an unsupported claim that every PHP process in the organisation has been examined.

A useful difference to explain to stakeholders is that a new image existing in a registry is a preparation step; the serving replicas using that image is a deployment fact. Ask for both pieces when the application uses containers.

Handle vendor backports without guesswork

Some supplier builds retain an older-looking upstream number while carrying a security fix. Preserve the full package or image revision and the vendor's matching advisory. Do not rely on a version banner alone to prove either vulnerability or remediation.

The current PHP update overview identifies the event-specific upstream releases. Keep that changing release reference separate from this reusable verification method.

What a defensible “verified” conclusion looks like

A strong conclusion names the hostname, request route, serving build, supplier patch evidence, worker replacement evidence and check time. It also states any contexts excluded from the check. A weak conclusion says only “php -v is green.”

These steps are a proposed verification method based on documentation reviewed on 22 October 2026. The short snippets are illustrative and do not probe a vulnerability. FinderPress has not executed a patch or restart on the reader's systems.