3. Restart and verify every instance
Installing a new binary leaves old worker processes in memory until they exit. Restart Apache for mod_php or the corresponding PHP-FPM services and pools. Restart queue workers and scheduled long-running processes too. Verify service start times, Web runtime version, package revision, health checks and every load-balanced replica. Delete any temporary diagnostic page immediately; do not leave phpinfo() publicly accessible.
1. Identify the actual Web runtime
Record the PHP branch, complete package revision, installation source, loaded extensions, service name and site handler. The CLI and Web server may run different binaries. In multi-PHP panels, inspect each site’s assigned handler. Inventory every FPM pool, Apache instance, image, queue worker and deployment replica. Keep a backup and a tested rollback plan before changing production.
Patching does not rule out compromise
A version comparison cannot determine whether exploitation happened. Preserve relevant logs and image evidence before cleanup, investigate unexpected worker crashes, files, processes and outbound connections, and follow your incident-response process. Missing error messages are not evidence of safety. If compromise is suspected, isolate affected systems and rotate exposed secrets from a trusted environment after containing the incident.
Command example / VERIFY
# Query the same runtime that serves your website.
php-fpm8.3 -v
systemctl show php8.3-fpm -p ActiveEnterTimestamp
ps -eo pid,lstart,args | grep '[p]hp-fpm'
# If using Apache mod_php, restart Apache, not just PHP-FPM.
# Also restart queue workers, schedulers and every container replica.