Verify a PHP security patch in the running web workers

The three questions a patch record must answer

These questions separate a maintenance action from a demonstrated security outcome. A team can install the correct files but leave old processes running. It can restart the wrong pool. It can update one replica while an old image remains eligible for autoscaling. Your record should make those possibilities visible and show how each one was resolved.

Define the scope before collecting screenshots. Name the production domains, their dynamic functions, the hosting model and the systems that can answer requests. If a provider controls the internals, obtain the provider’s scoped confirmation rather than inventing evidence you cannot observe. Clear limits make a report more credible, not less useful.

Identify the web SAPI instead of assuming CLI equivalence

PHP’s manual distinguishes the interface used by the running interpreter, such as cli or fpm-fcgi. Its version function reports the current parser’s version. This means a terminal command tells you about the interpreter launched by that command; it does not automatically establish which interpreter handles an HTTPS request. Trace the web server’s virtual host to its handler, socket or upstream application service.

If your existing authenticated operational tooling needs minimal runtime fields, a server-side helper can return them without printing a full diagnostic page. The following example belongs inside that protected tooling, outside the public document root. It is not a standalone endpoint to upload publicly. Running it in a shell will intentionally describe CLI, so use it in the context you are investigating.

<?php
declare(strict_types=1);
return [
    'version' => phpversion(),
    'sapi' => php_sapi_name(),
    'process_id' => getmypid(),
];

A process identifier helps correlate observations with an administrative process record. It is not a secret token or a security credential. Keep diagnostic output private and collect only what is necessary; configuration dumps and environment variables are rarely needed to establish this basic mapping.

Tie the installed artefact to a trusted fix

For distribution packages, retain the complete installed revision, repository origin and advisory that identifies the corrected build. For a managed platform, retain the provider’s dated statement covering the actual plan and runtime. For an internally built interpreter, retain the source revision, reviewed patch references, build provenance and deployed artefact identity. “Built this morning” is not enough if nobody can say which source changes were included.

The same principle applies to backports. Avoid both errors: declaring a maintained package vulnerable solely because its base version is older, and declaring an arbitrary old package protected because some other vendor backported the issue. The mapping must concern the supplier and build that your service actually uses. Where evidence is missing, record an unresolved verification task instead of changing the wording to “safe”.

Verify process replacement, not just a restart request

Use the service manager or orchestration system to confirm that the operation completed and the identified runtime is active. On a systemd-managed PHP 8.3-FPM installation, these read-only examples can support that record after the administrator has applied the correction and performed the appropriate restart. They are examples for that named service; a panel, container or different branch requires its own mapping.

systemctl is-active php8.3-fpm
systemctl show php8.3-fpm -p MainPID -p ActiveEnterTimestamp -p ExecStart
journalctl -u php8.3-fpm --since "30 minutes ago" --no-pager

A service start timestamp is not proof of patch content, and patch content is not proof that every old worker has gone. Check the supplier’s restart or reload semantics. Where a graceful operation allows existing requests or workers to drain, keep the verification open until old execution contexts no longer serve the affected workload. Investigate failed pools and orphaned service instances rather than assuming the new parent process covers them.

Use protected FPM status carefully, and do not confuse caches with binaries

The PHP-FPM status interface can expose pool start times and process information. The PHP manual explicitly advises restricting it to internal requests or known client IPs because it reveals operational details. If your organisation already uses a properly restricted status facility, correlate it with the service record. Do not expose a new public status page just to make the report easier to collect.

Clearing OPcache is a different operation. PHP documents opcache_reset as a reset of the in-memory opcode cache, after which scripts are reloaded and parsed again. That does not install a new interpreter binary. Likewise, clearing a CDN cache changes cached responses rather than the runtime. Record cache work when it is relevant to application behaviour, but do not accept it as the evidence that a runtime security update is active.

Cover every replica, origin and future restart

In a container environment, a new image existing in a registry is not evidence that the deployment uses it. Retain the immutable image digest, rollout result and identities of the running workloads. Check that new replicas will be created from the corrected artefact. Review scheduled tasks, separate worker deployments and disaster-recovery templates if they run the same affected runtime.

For multiple origin servers, verify each eligible node. A load-balanced request may repeatedly reach one healthy node, especially where routing or session affinity is involved. Use approved internal routing or platform inventory to account for the others. Keep the ability to return to service conditional on verification: an unpatched standby should not become a surprise production server during the next capacity event.

• Production and staging request paths accounted for.
• Every active runtime family and service owner identified.
• All eligible origin nodes and replicas checked.
• Autoscaling, job and replacement templates use the corrected artefact.
• Rollback targets reviewed so an old vulnerable build is not restored accidentally.

Build a practical acceptance record

Service/domain:
Runtime supplier and handler:
Fixed-build advisory/reference:
Installed revision or image digest:
Node/pool/replica scope:
Process replacement completed at:
Web-runtime observation and collection method:
Business tests and error review:
Remaining limits or exceptions:
Owner and next review date:

Keep this record private and precise. Include the time zone for timestamps and distinguish “reported by provider” from “observed by administrator”. A screenshot can supplement the record, but a written explanation is easier to review and less likely to leak unrelated configuration. If an exception remains, name its containment and deadline rather than hiding it in a green overall score.

Example: the fixed CLI is not the live web service

A hypothetical shop uses a distribution CLI interpreter for scheduled exports and a separate FPM package for checkout. An administrator upgrades the CLI and sees a satisfactory version result. The web-runtime observation still points to the old pool. Tracing the checkout virtual host reveals the second supplier. The team updates that package, replaces the correct workers and validates checkout in test mode.

The final conclusion is now narrowly supportable: the named services use the verified correction. It does not claim that no intrusion occurred before the change or that every application vulnerability has disappeared. For PHP2Shell or any urgent interpreter update, this clear evidence chain is a stronger operational result than collecting more unconnected version screenshots.