PHP2Shell fix guide for cPanel

Identify each domain’s assigned PHP version

Use MultiPHP Manager or the hosting provider’s equivalent to record the assigned PHP version and handler for every domain. Check PHP-FPM status and any inherited setting. Systems with CloudLinux or third-party selectors may use a different vendor’s packages.

In WHM, have an authorized administrator inspect EasyApache package status and the full revision. Match the responsible package supplier’s security guidance for both CVEs. Do not use an Ubuntu package threshold for an EasyApache build.

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.

Update through the supported management path

Ask the host or WHM administrator to apply the vendor’s supported updates. Test account compatibility and extensions before changing a PHP branch. Back up site files, database and relevant account configuration, and confirm how restoration works.

After applying the update, verify the selected version is active for each domain and that affected FPM or Apache workers were replaced. A control panel showing a version option does not prove the patch is installed or selected.

If you only have account access

Request the exact package revision, evidence for both CVEs and restart confirmation from the provider. If no fixed runtime is available, discuss temporary access restrictions or migration. Do not attempt system-level package changes from a shared hosting account.

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.