PHP2Shell fix guide for Nginx

Trace the FastCGI upstream

Review the active virtual-host configuration using authenticated server access. Identify fastcgi_pass targets, upstream groups and any PHP_VALUE or PHP_ADMIN_VALUE parameters. A socket path or container service name points to the runtime you must inventory.

Nginx configuration dumps can include sensitive internal names or values. Inspect them privately; do not paste complete output into a public form. Map each domain and pool, including alternate upstream servers.

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.

Patch FPM through its package or image supplier

Use the operating system or Docker guide for the FPM process behind each upstream. Configuration-based exploit reachability differs across deployments, but absence of a particular FastCGI parameter is not proof of immunity.

Restart or replace the PHP workers and verify their build. Use the Nginx configuration test before applying any frontend changes. A frontend reload is necessary only for frontend configuration changes, and is not evidence that PHP has been fixed.

sudo nginx -t

Validate routing and health

• Confirm the domain reaches the intended fixed FPM pool.
• Check fastcgi socket permissions, upstream availability, timeouts and error rates.
• Test uploads and sessions, and confirm no stale backend remains in a load-balanced group.

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.