Exposure assessment ≠ compromise detection. This guide cannot determine whether a particular system was compromised. Verify the current advisory and your exact runtime.

Preserve evidence and build a timeline

Record when each instance became exposed, when it was patched, and when workers were replaced. Preserve web access and error logs, PHP and service logs, WAF events, cloud audit trails and relevant authentication records. Retain original timestamps and time zones.

If active compromise is suspected, involve your incident lead. Plan isolation and collection together. Restarting, deleting suspicious files or rebuilding can destroy volatile evidence. Preserve snapshots and logs using your approved process; do not download untrusted files into a public web directory.

Correlate request and runtime signals

  • Look for unusual bursts of worker crashes, HTTP 500 responses, memory exhaustion or fatal errors around suspicious requests. These also have ordinary operational causes.
  • Review unexpected multipart traffic and anomalous session response data against the research guidance. Traffic patterns alone do not prove successful execution.
  • Correlate request IDs, worker or container identifiers and timestamps across the proxy, PHP runtime and WAF.
  • Missing logs or missing signatures do not establish that no compromise occurred.

Review processes, connections and files

Compare PHP worker child processes, outbound connections and executable paths to your known baseline. Permission restrictions may hide process or connection details. These commands do not constitute a compromise detector.

Compare application code to trusted version control or a clean release artifact. Review web-writable directories for unexpected executable files, modified scheduled jobs, service units and new administrator accounts. Modification times alone are weak evidence and can be altered.

Linux read-only process and TCP inventory
ps -eo pid,ppid,user,lstart,args
ss -tpn

Containment and credential decisions

For confirmed or credible active compromise, isolate affected workloads in coordination with the response team. Rebuild from trusted sources and address the original exposure. Preserve evidence before removing persistence.

Rotate credentials and revoke relevant sessions from a trusted environment when exposure or compromise justifies it. Include application secrets, deployment credentials and cloud roles within the affected scope. Avoid rotating secrets into a still-compromised runtime. Memory disclosure may occur without a web shell being left on disk.

When to bring in incident response

Escalate when you see unexplained privileged activity, attacker persistence, data access, unknown outbound traffic or an uncertain scope across systems. A professional investigation may require forensic collection and legal or notification decisions. This website cannot certify that a server is clean.

CHECK THE ORIGINAL GUIDANCE

Sources & further reading

PHP advisory · Out-of-memory corruption↗PHP advisory · Stale global state↗PHP2Shell research hub↗Datadog Security Labs · PHP2Shell↗

Advisory snapshot: 2026-10-22. Next review due: 2026-10-29. Recheck sources before acting; this site does not update advisories automatically.