PHP2Shell fix guide for Cloudflare

Verify the traffic path and protections

Cloudflare’s published guidance describes deployed WAF protections for PHP2Shell. Review current guidance and your account’s active rules. Paid customers should confirm the relevant Managed Ruleset operates in the intended blocking mode.

Confirm the relevant hostname is proxied and that requests cannot casually bypass the proxy to reach the origin. Origin access restrictions depend on the architecture and must preserve health checks, trusted integrations and administrative recovery. Do not apply an untested firewall allowlist to an unknown server.

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 behind the proxy

Identify and update the origin’s actual PHP packages or container images using the corresponding environment guide. Replace every worker and test the application through its normal traffic path.

WAF detection evolves as attack patterns change. Blocking some requests does not prove all vectors are covered, and a lack of WAF alerts does not establish that the origin has not been targeted or compromised.

Use events as investigation evidence

• Preserve relevant WAF event timestamps and request identifiers.
• Correlate events with origin access logs, PHP errors and worker crashes.
• Distinguish a blocked request, an allowed suspicious request and evidence of successful execution.
• Retain protections during and after remediation, while tuning false positives through change control.

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.