How to Detect PHP2Shell and Node2Shell

A PHP out-of-memory error can show someone tried PHP2Shell. A web-server process launching an unexpected program can show what happened afterward. Neither signal, on its own, proves which vulnerability was used.⁠¹⁠² If you run internet-facing PHP or Node.js, collect error logs, process events and network telemetry together, then patch the affected runtimes. A detection rule is not a fix.

The complete PHP2Shell and Node2Shell guide covers the vulnerabilities and patches. This page covers the detection rules: what to collect, what to alert on and what a clean result cannot tell you.

How you'd notice PHP2Shell in error logs

Elastic's prebuilt rule, Potential PHP2Shell Exploitation Attempt, looks for a PHP fatal memory error containing four specific pieces: PHP Fatal error, Allowed memory size, bytes exhausted and Unknown on line 0.⁠¹ The last part matters. It can indicate that the error occurred before a normal application script was running. Elastic searches Apache, nginx and Apache Tomcat error-log datasets for the combination.

Reported Elastic describes the rule as an indicator of attempts against CVE-2026-109618 and CVE-2026-109619, including attempts that fail. It does not confirm remote code execution.⁠¹ A real application defect, stress test, deliberately low PHP memory limit or approved security assessment can generate similar errors. Check the complete message, the host and the surrounding requests before escalating.

The rule also depends on collection. If PHP writes its errors to a separate PHP-FPM log that your SIEM never ingests, an Apache or nginx rule may not see them. Keep the original message, timestamp, hostname, dataset and log path. An alert's source.ip may identify your CDN or reverse proxy rather than the external sender; recover client identity from trusted edge logs, not an arbitrary forwarded header.

A matching error deserves investigation. Its absence does not clear the server.

HTTP 5xx spikes show pressure, not code execution

Sumo Logic published two Cloud SIEM outlier detections on 23 October: OUTLIER-S00036, Spike in HTTP Server Errors from Source IP, and OUTLIER-S00037, Spike in HTTP Server Errors to Destination IP.⁠² Both look for abnormal server-error activity. A burst of failed requests against one host, or across hosts from one source, can justify looking at the PHP errors and process events occurring at the same time.

These rules are noisy without a baseline. Deployment failures, overloaded workers and application bugs can all increase HTTP 5xx responses. Sumo Logic says its outlier rules need populated web_servers or http_servers match lists. Tune them against each application's usual rate rather than applying one threshold to every website.

Amazon Threat Intelligence reported PHP2Shell attempts in its MadPot honeypots from 17 October, four days before public disclosure.⁠¹¹ That makes 17 October a useful starting point for historical searches, if you have retained the data. AWS did not claim every observed attempt succeeded. Preserve the logs even when their error counts look ordinary.

Process and network events carry stronger evidence

A successful exploit may let the attacker execute commands under the web service's account. The useful signal is then an unexpected program or connection associated with a PHP worker, Apache process or other web-facing service. Sumo Logic names three relevant detections: MATCH-S00164, Suspicious Shells Spawned by Web Servers; MATCH-S00174, Web Services Executing Common Web Shell Commands; and MATCH-S00539, Web Servers Executing Suspicious Processes.⁠² They detect behavior compatible with compromise, not PHP2Shell specifically.

Elastic's Suspicious Child Execution via Web Server rule takes the same approach on Linux, using process-execution events from Elastic Defend.⁠⁶ Watch for unexpected shells, interpreters, discovery commands or download utilities launched by web-server workers. On Windows, Security Event ID 4688 records process creation when the relevant auditing is enabled, including process ancestry and, with additional configuration, command lines.⁠⁷

Opinion A PHP memory-error alert followed by suspicious process execution on the same host is stronger evidence than either event alone. Add unexpected outbound network connections to the correlation: a web worker contacting an unfamiliar destination may be downloading software or sending data. None of these observations proves which CVE provided access. They can also miss in-process activity that never launches a child process.

Node2Shell may replace the process you are watching

Node2Shell needs different detection assumptions. CVE-2026-111497 corrupts memory inside a vulnerable Brotli decoder, and the program using that decoder may crash, continue running or execute attacker-controlled code. Sysdig's Node.js Process Crash Followed by In-Place Program Execution managed rule correlates a Node.js crash with suspicious execution afterward in the same workload.⁠⁸ On 28 October, Sysdig also documented Node.js Process Redirected Network Socket to Standard Stream, intended to catch a post-exploitation behavior.

Reported Tanium's 27 October laboratory report found that successful exploitation in its container test replaced the Node.js process rather than spawning a separate child shell. Repeated failures crashed and restarted the service within minutes.⁠⁹ Tanium did not reproduce the same execution outcome on its host installation, which crashed instead. A rule limited to a Node.js parent starting a shell would have missed its successful container test.

ELLIO separately reported observing Node2Shell exploit traffic in its sensors on 26 October and reproducing code execution on selected vulnerable Node.js builds in its laboratory.⁠¹⁰ Sysdig's updated account calls this confirmed exploitation; ELLIO's observation establishes exploit delivery in the wild, not a confirmed compromise of an identified victim. CISA's later KEV entry confirms exploitation status without documenting an affected organization.⁠⁵

A crash-and-restart loop is worth paging on when the service processes untrusted Brotli data. It is still a symptom, not a signature. Faulty application code, memory pressure and infrastructure changes can produce the same pattern. A successful exploit need not leave a crash, and a process may be replaced without the parent-child relationship your ordinary execution rule expects.

WAF alerts and clean scans have different blind spots

A web application firewall (WAF) sees requests at the edge. It can identify or block traffic matching a vendor's PHP2Shell or Node2Shell rule, and its event records help identify which backend received the request. It cannot tell whether the vulnerable worker executed code, leaked memory or wrote a file. Sumo Logic recommends correlating WAF observations with process detections rather than treating them as an independent confirmation of compromise.⁠²

The same distinction applies to vulnerability scanners. A scanner that identifies an outdated PHP or Node.js release is finding potential exposure. It is not determining whether someone exploited it last week. The PHP2Shell scanner and checker guide covers that separate job. Scanner silence can also come from a missed bundled runtime or a distribution package whose version number does not reveal a backported fix.

Reported Eon's 28 October investigation guide noted that a successful PHP2Shell exploit could produce a normal HTTP response and leave no fatal error. It also reported no publicly identified victim-specific web-shell names or file hashes at that time.⁠¹² I found no independently validated detection-rate figures for the vendor rules above. Do not turn their existence into a claim of comprehensive coverage.

Memory disclosure is harder still. A process can expose secrets without launching a command or creating a file. Error logs, process telemetry and WAF alerts may all remain quiet. If you are investigating suspected compromise rather than building alerts, follow the post-incident evidence and recovery checklist.

There is also a separate PHP issue, CVE-2026-115560. PHP's 23 October advisory recommends session.upload_progress.enabled=0 for the relevant uncommon configuration until a fix is released.⁠³ I did not find a vendor rule specifically designed to detect exploitation of that CVE. Do not assume the PHP2Shell memory-error rule covers it.

Collect the signals, patch, and assign an owner

Do today

1. Inventory internet-facing PHP and Node.js services, including containers and vendor-packaged runtimes, and identify which still require patches.
2. Enable centralized PHP, Apache and nginx error logs with original messages, host identifiers and timestamps.
3. Collect process-creation and network-connection telemetry from the web hosts, including process ancestry where available.
4. Enable Elastic's PHP2Shell attempt rule or an equivalent detection that matches the documented error pattern.
5. Alert on suspicious web-worker execution, unexpected outbound connections and repeated PHP-FPM or Node.js crash-and-restart loops.
6. Assign an on-call owner and escalation path for each high-confidence correlation.
7. Patch PHP to the applicable fixed or vendor-backported build and Node.js to a fixed runtime, then restart the affected workers.

Do this week

8. Baseline HTTP 5xx rates by host and source so Sumo Logic's outlier rules, or their equivalents, have useful thresholds.
9. Correlate WAF alerts, PHP errors, process events and network connections using host identity and timestamps, allowing for clock differences.
10. Search retained PHP and cloud audit telemetry from at least 17 October, following AWS's earliest reported exploitation window.
11. Test the detection pipeline in staging with benign memory-limit failures, approved process-creation tests and controlled service restarts. Do not use live exploit code.
12. Measure whether each test produces the expected event, reaches the SIEM and pages the assigned owner. Record false positives and collection gaps.

Can wait

13. Defer custom exploit-signature development until the available behavioral detections are collecting the right telemetry.
14. Tune published source-IP indicators only as investigative context, since shared infrastructure can generate unrelated traffic.
15. Revisit vendor detection logic when new rule versions, validated victim indicators or additional exploitation evidence appear.