PHP2Shell fix guide for Laravel

Map the application’s execution paths

Identify the web handler, FPM pool, containers, Horizon or queue workers, scheduler and any long-running application server. A deployment may run different PHP builds in its web and worker images.

Check composer.json constraints and the lock file against the target PHP version. Test extensions and platform requirements in the intended deployment environment. Do not bypass platform checks to make an incompatible upgrade appear successful.

php -v
composer check-platform-reqs

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.

Deploy the fixed runtime through the normal release path

Update the operating system package or base image that supplies PHP. Test application boot, authenticated requests, database access, cache and session drivers, uploads and job processing before sending production traffic.

Restart or replace FPM and long-running workers using your supervisor or orchestrator. Laravel queue:restart requests graceful worker exit; it relies on worker supervision and does not replace the system PHP runtime. Octane and similar services need their own supported reload or replacement procedure.

Check background work after the release

• Confirm no old queue worker or scheduler container remains on the vulnerable build.
• Verify that newly spawned processes use the intended binary and configuration.
• Monitor failed jobs, error rates and latency, and avoid applying schema changes merely to patch PHP.

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.