PHP2Shell fix guide for Plesk

Record the selected domain handler

In the domain’s PHP Settings, record the version and handler type. Ask an authorized administrator to match that handler to the installed Plesk or operating system package and full revision. Multiple PHP versions can coexist on one server.

Review subscriptions, subdomains and background tasks. A system CLI update may leave a Plesk-supplied runtime untouched. Confirm which vendor provides the fix and whether both CVEs are addressed.

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.

Install and apply the supported update

Use the supported Plesk or distribution update mechanism appropriate to the handler. Test extensions, PHP settings and application compatibility, and make recoverable backups before changing the selected branch.

Replace the affected PHP workers through supported service controls. Verify each domain’s handler mapping after the change and test HTTP requests, uploads, sessions and scheduled tasks. Keep a change record with package revisions and restart timestamps.

Escalate a missing fixed handler

If a fixed supported handler is not available, contact the provider with the exact platform and package details. A visible older version can be a patched backport, but only the supplying vendor can substantiate that build. Restrict exposure while resolving the gap.

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.