PHP2Shell fix guide for PHP-FPM

Inventory pools and binaries

Service names vary by distribution, third-party packages and control panels. Containers may not use systemd. Map the frontend socket or upstream address to the specific FPM master and pool before choosing an update path.

CLI configuration and FPM configuration may differ. Inspect authenticated service administration and package ownership, not just the php command on your shell PATH.

ps -eo pid,ppid,user,lstart,args
systemctl list-units --type=service --all 'php*-fpm.service'

Before you change the runtime

Record the current package revision, runtime handler, configuration and deployment topology. Confirm a current fix for both CVEs from the responsible vendor. Back up application data and configuration using a tested restore process. If an incident is suspected, preserve evidence before changing processes or files.

Test the intended PHP build with the application, extensions, scheduled jobs and database in staging. Plan a maintenance window or a rolling change with health checks. Keep a configuration and application rollback plan; do not restore a vulnerable runtime to public traffic without restricting exposure.

Apply the fixed package and replace workers

Follow the exact distribution or image supplier’s security notice. Test the intended configuration with the installed FPM binary’s supported test option in staging. Schedule the service restart or orchestrated replacement and monitor health.

Confirm old worker processes are gone across every pool and instance. Keep capacity for connection draining and session behavior. A successful package install does not prove an already running worker has loaded the fixed engine.

Avoid false configuration assurances

The stale-state advisory includes a validated application-dependent FPM path. Recycling workers or disabling one optional feature does not cover all producers and consumers. Treat advisory workarounds as limited temporary measures and assess their operational cost.

Verify the result and handle a delayed patch

Check the actual web-serving binary, package revision or image on every instance. Replace old workers and verify their startup times. Validate application health, uploads, sessions, queue workers and scheduled jobs. CLI output alone does not prove what serves HTTP requests.

If a fixed deployment fails compatibility checks, restrict access and escalate to your vendor or administrator. Temporary WAF or configuration changes may reduce specific attack paths but are not a complete substitute for patching. Investigate suspicious activity separately: a successful update cannot establish that the system was never compromised.