How do I detect PHP2Shell exploitation?

What PHP2Shell exploitation looks like in logs and host activity

Detection starts with the request trail. Look for unauthenticated hits to PHP endpoints that do not fit normal browsing patterns, then correlate them with server-side behaviour that should not happen during ordinary page delivery, such as interpreter-driven command execution, child shells, or PHP workers touching paths they normally never need.

Separate the signal from background noise by comparing the request method, user agent, referrer and endpoint against your baseline for each application. A single suspicious request is rarely enough on its own, but repeated probing, parameter variation and immediate host activity after the request are strong indicators that the web layer is being used as the entry point.

For background on the exploit and its incident triage context, use the PHP2Shell guide alongside the PHP2Shell campaign tracker to align what you are seeing with known exploitation activity and reporting timelines.

Host artefacts that matter after initial access

Once PHP2Shell is suspected, the hunt should move from web logs to endpoint evidence. Unexpected processes spawned by the web server or PHP runtime, shells launched under web context, and new files in web-accessible directories are the most useful artefacts because they show the request has crossed from probing into execution.

Also check for persistence and staging behaviour. New local accounts, changes to startup locations, scheduled execution, and unusual outbound connections from the web host can indicate that the attacker is not just testing code execution but trying to keep access or move data out. The key question is whether the web tier remains the only touched system or whether it has already become a pivot point.

For prioritisation, confirm whether the affected systems fall into the active exploitation window and whether they need emergency handling rather than routine backlog treatment. The CISA Known Exploited Vulnerabilities Catalog, the NIST National Vulnerability Database and the FIRST EPSS are the most practical external references for deciding whether to escalate the hunt.

How to confirm exposure without missing earlier compromise

Validate exposure by inventorying every PHP-facing site, virtual host, container and application server, not just the internet-facing front door. Review activity back to the first advisories on 21 October 2026, because exploitation can start before defenders recognise a pattern and the useful evidence may already be older than your most recent alert window.

If patching or mitigation is delayed, preservation becomes as important as detection. Keep copies of relevant logs, capture volatile process and network state where possible, and look for the earliest suspicious request so you can build a timeline that connects web access, execution and any subsequent outbound activity. That timeline is what tells you whether you are dealing with a single failed attempt or a broader compromise.

For exploitability triage and response sequencing, the Zero-Day and Exploited Vulnerabilities Guide and the SSVC Guide help frame whether you should move immediately to containment, mitigation or full compromise assessment.

Practitioner Guidance

What to prioritise: Start with the web tier and treat the first suspicious request as the anchor point for the investigation. The highest-value evidence is the join between request logs, process creation, file changes and outbound network activity, not any one artefact in isolation.

What to verify: Confirm whether the same host shows both web-layer anomalies and post-exploitation behaviour. If you only see unusual requests, stay in triage; if you also see command execution, new files or outbound beacons, shift to compromise assessment and containment.

Practitioner takeaway: The main mistake is stopping at “was the exploit attempted?” instead of proving whether the attempt reached execution, persistence or egress. For PHP2Shell, that distinction determines whether you are hunting suspicious traffic or responding to an active host compromise.

Related resources from NHI Mgmt Group

• Detect
• How can organisations detect AI reconnaissance before exploitation?
• How should security teams detect exploitation of internet-facing applications before EDR alerts?
• How do security teams detect post-exploitation tooling that avoids normal malware artefacts?