Was it an attempt, or a successful intrusion?
An unusual multipart request or a WAF alert can indicate an attempt. OOM messages, SIGSEGV/SIGABRT and bursts of HTTP 500 can also have ordinary causes. Unexpected PHP child processes, outbound connections, modified files or unauthorized accounts warrant urgent investigation, but attribution still needs evidence. Memory disclosure may leave no webshell or new file. A clean file scan cannot rule it out.
Build a timeline across several logs
Keep the original timezone and record any clock skew. Correlate reverse-proxy request IDs and access times with PHP/FPM error logs, worker PID, WAF events and process/network telemetry. Compare suspicious requests with anomalies in the RESPONSE Set-Cookie PHPSESSID, not merely inbound cookies. The local tool only highlights broad text patterns: long or percent-encoded session values are review prompts, not signatures proving PHP2Shell.
No match does not mean no compromise
Standard access logs often omit bodies, response headers and session values. Encrypted traffic is invisible to a network sensor without approved decryption. Retention gaps, load-balancer replicas and memory-only activity create blind spots. Record which hosts and time ranges you actually reviewed, obtain host-provider logs where possible and escalate unresolved high-risk findings. Updating PHP prevents future exposure; it does not establish what happened earlier.
journalctl -u php8.3-fpm --since "2026-10-21 00:00:00 UTC" --until "2026-10-22 23:59:59 UTC" --no-pager
journalctl -k --since "2026-10-21 00:00:00 UTC" --no-pager
ps -eo pid,ppid,lstart,args
ss -tpn
# Only use an independently trusted pre-incident manifest:
sha256sum -c /path/to/trusted-manifest.sha256Primary sources & further reading
PHP security teamRead the original ↗CVE-2026-109618Read the original ↗CVE-2026-109619Read the original ↗php2shell.ukRead the original ↗Research & practical guides
PHP2Shell tools
Check a public website, review local configuration and logs, or find maintained response tools. Each result explains its evidence and its limits.
01PHP2Shell in plain language
PHP is the engine running your website; WordPress, Laravel and plugins sit above it. Updating a plugin does not update PHP. Two runtime memory-safety flaws can turn abnormal request cleanup into disclosure or code execution. A public website check can find clues, but only the host or server administrator can verify the actual Web runtime and its patch.
02Was it an attempt, or a successful intrusion?
An unusual multipart request or a WAF alert can indicate an attempt. OOM messages, SIGSEGV/SIGABRT and bursts of HTTP 500 can also have ordinary causes. Unexpected PHP child processes, outbound connections, modified files or unauthorized accounts warrant urgent investigation, but attribution still needs evidence. Memory disclosure may leave no webshell or new file. A clean file scan cannot rule it out.
03Preserve evidence before changing the host
Record discovery time, domain, instance, runtime, current symptoms and the last known good state. Export original access/error/WAF and process logs with their timezone; preserve cloud audit records and authorized disk or memory snapshots when available. Store copies with restricted access and hashes. Do not upload cookies, tokens or customer data to public scanners. Avoid clearing logs or deleting suspicious files before evidence is captured.
04Reading Wiz and Calif without overgeneralizing
Wiz and Calif explain why request-lifecycle failures can outlive the request that caused them. The official advisory for CVE-2026-109618 demonstrates mod_php RCE; FPM susceptibility is source-based, without a complete demonstrated FPM exploit for that CVE. CVE-2026-109619 separately confirms an application-dependent FPM upload-progress path. Read each GHSA for its precise evidence instead of treating every SAPI as an identical proven exploit.
05Cloudflare: why response visibility matters
Cloudflare describes full-transaction detection using both request and origin response, allowing a matched response to be blocked before potential data leaves the proxy. This is useful for disclosure paths that do not launch a shell. The article’s rollout time is a historical snapshot, not a guarantee for your account: verify rule availability, routing, exclusions and event logs. Direct-origin paths and unproxied hosts still need patching and review.