PHP2Shell repair for an unmaintained PHP site

01

Recover control before changing software

Find the domain registrar, hosting account, server or panel access, source files, database credentials and billing owner. Record who can approve a maintenance window and restore service. Identify the application from local files and its exact release, not the visible theme. If credentials or the source are missing, recover them before a production PHP switch.

02

Preserve evidence and rehearse restoration

If compromise is suspected, retain access, error and application logs before cleanup and follow the incident-response guide. Back up code, database, uploads, configuration and scheduled jobs as one dated set. Record encoding and external storage. Restrict and encrypt backups; restore to a private environment and verify content and login. A successful backup message is not a restore test.

03

Map the PHP generation gap

PHP 5.3/5.6 applications can depend on mysql_* and other removed APIs. PHP 7 removes ext/mysql; PHP 8 removes each() and create_function() and tightens signatures and types; PHP 8.2 reports dynamic-property deprecations. Read every crossed migration guide. Old framework minima are historical facts, not supported deployment choices. A matching PHP number alone cannot validate custom code.

04

Choose repair, staged migration or an archive

A verified vendor patch on the existing branch may reduce urgent exposure while compatibility work proceeds; require evidence for both CVEs and check ongoing support. Unsupported PHP needs a supported migration target, not a permanent WAF exception. Repair an actively used application when ownership and tests exist; rebuild when dependencies are abandoned; consider a static archive for content-only sites after removing login, search and forms that need a backend.

05

Build a representative private rehearsal

Match Web PHP, extensions, INI, database and web-server routing to the planned target. Keep sanitized copies access-restricted and prevent staging from sending real mail, charging cards or calling production webhooks. Update framework, plugins and custom code as a compatible set. Exercise the product-specific business checklist and save logs and observed results. Non-technical owners can ask the host for these records.

06

Design rollback around writes and schema changes

Keep a matched application-and-database restore set. A PHP selector rollback cannot reverse a schema migration. Before final copying, coordinate an order/content write freeze or a documented synchronization method. Set failure criteria, a responsible operator and a time limit. Account for orders written after the snapshot; test restoration and data reconciliation instead of discarding customer transactions.

07

Verify the running service after cutover

Confirm the PHP actually serving the domain, every FPM pool, queue worker, scheduled task, container and replica. Replace old workers and check startup errors. Verify both CVE fixes using upstream versions or vendor backport advisories, then test deep links, login, uploads and business flows. Keep logs and a monitored rollback window. CLI php -v and a working home page are insufficient.

Check site functions after the PHP2Shell fix

PHP2Shell patch verification

Application compatibility, application support and PHP security are separate checks. Choose a supported PHP branch with both CVE fixes, then verify every Web worker, scheduled task and replica. Updating a framework or plugin alone does not replace the PHP interpreter.