PHP2Shell fix guide for WordPress

Find the runtime behind this domain

In WordPress administration, Tools → Site Health → Info → Server can provide a useful version clue. Confirm it against your host’s domain-level PHP handler and the complete package revision. Do not install a public phpinfo() file.

Check production, staging, multisite installations, alternate domains and scheduled jobs. Different sites on the same account may use different PHP versions. Managed hosts may patch the runtime without changing the visible upstream version.

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.

Coordinate the host update

• Ask the provider whether both CVEs are fixed for the PHP handler assigned to your domain. Request the notice or package revision and worker restart confirmation.
• Back up both the database and files. Test the selected PHP build with your active theme, plugins and custom code in staging.
• Use the supported hosting control to change PHP only after checking compatibility. A version selector may require a separate Apply action.
• Retest login, checkout, forms, media uploads, cron and caching. Review unexpected administrator accounts if exposure or other evidence is concerning.

Managed hosting is a provider question

A managed service may have completed remediation, but a brand-level announcement is not proof for every product or account. Ask whether your specific service is covered. Avoid changing WordPress code as a substitute for a host-level patch.

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.