← All posts

Detecting PHP2Shell: a detection engineering strategy

By · · 11 min read

Patch first. Direct exploitation of PHP2Shell is hard to detect, so watch for what attackers do after they get in. Look for exploit fingerprints in web server error logs and for post-exploitation commands run by the web server user.

On 21 October 2026, researchers from Wiz, OpenAI and Calif jointly disclosed two critical PHP vulnerabilities, dubbed PHP2Shell. CVE-2026-109618 and CVE-2026-109619 can lead to pre-authentication remote code execution (RCE) or leak sensitive memory contents.

No working proof-of-concept (PoC) exploits are public yet, but Amazon and Cloudflare have both seen attempted exploitation, and Wiz and Calif demonstrated working private PoCs. AI-assisted patch analysis will probably make exploit development practical for less skilled threat actors too.

Detecting the exploitation of memory corruption bugs like these directly is often not possible. Network IPS/WAF rules work, but their signatures tend to be fragile, specific to one exploit, and dependent on TLS inspection.

That leaves host and application logs, which show post-exploitation activity. They're the most effective option defenders have. It may feel second-best, but a solid set of host detections catches known and unknown attacks alike.

PHP2Shell in 90 seconds

The bug

When PHP runs out of memory mid-request it aborts, skipping cleanup code and leaving stale data behind. Attackers can use that in two ways:

  • Sensitive memory exposure. A Heartbleed-style brute-force attack leaks memory contents, such as API keys or passwords, into the PHPSESSID session cookie.
  • Remote code execution. Attackers can use the stale state to run code directly in the PHP worker process as the web server user (typically www-data or apache).

What's affected

The vulnerabilities are in the core PHP runtime, so any PHP application may be affected.

  • Researchers demonstrated exploits against WordPress, Drupal and Joomla. It's not yet clear whether exploits must be tailored to each application or can be generic.
  • Apache with mod_php is the most exposed.
  • Nginx with PHP-FPM was also exploitable.
  • Linux is likely the most common target, and it's the focus of this post.

Detection recommendations

Exploitation may show up in Apache and Nginx error logs as a PHP Fatal error. After that, attackers will most likely use common discovery, execution and persistence techniques.

  1. Onboard web server error.log and access.log into your SIEM.
  2. Configure auditd with a comprehensive ruleset, or install Sysmon for Linux or a commercial EDR, and onboard those logs to your SIEM.
  3. Deploy exploit fingerprint detections for PHP Fatal error and Failed to decode session object against the web server error.log.
  4. Deploy detections for common Linux post-exploitation commands, webshells, wget downloads and bash reverse shells.
  5. Baseline web server user activity, process trees and network connections, then hunt for or alert on anomalies.

Detection strategies

Linux's default logging is poor, and it can be configured in many different ways. That makes deploying detections quickly much harder than on Windows.

Treat the detections below as a starting point. They'll need tuning for your environment.

Strategy 1: exploit fingerprints in web server error logs

Look for PHP Fatal error (memory exhaustion) or Failed to decode session object messages in Apache and Nginx error.log files. A single error is common in healthy applications; a burst from one client is the brute-force fingerprint.

Detection What it catches Severity
PHP Memory Exhaustion Before Script Execution A single Allowed memory size of N bytes exhausted ... in Unknown on line 0 fatal. This means an attempt or a scan, not a compromise. Medium
PHP Session Decode Failure The Failed to decode session object. Session has been destroyed warning that follows the memory-exhaustion bailout Medium
PHP Memory Exhaustion Before Script Execution, Burst Three or more of those fatals from one host within 15 minutes. CVE-2026-109618 exploitation needed about 590 requests in the public research. High
PHP Memory Exhaustion Followed By Session Decode Failure A memory-exhaustion fatal and a session decode failure on the same host within 15 minutes, the "arm" stage of the exploit High

The burst and correlation detections are much stronger signals than either single event. The rule files also list where these errors are logged for Apache with mod_php, Nginx and Apache with PHP-FPM, and RHEL-family PHP-FPM.

Strategy 2: post-exploitation activity by the web server

Detect post-exploitation commands whose parent is apache2 or php-fpm, or that run as the www-data or apache user. Also watch for webshell files created in web server directories and other signs of hands-on-keyboard activity.

Auditd detections

Category Rule What it catches
Webshell Sigma: Webshell Remote Command Execution (c0d3734d) Any program run by the web server user
Hacktool Sigma: Linux HackTool Execution (a015e032) Known attacker tools: linpeas, pspy, nuclei, ffuf, sliver, hydra…
Reverse shell Sigma: Suspicious Use of /dev/tcp bash -i >& /dev/tcp/…-style reverse shells
Download & execute Sigma: Program Executions in Suspicious Folders (a39d7fa7) A payload run from /tmp, www or public_html after curl/wget fetches it
Discovery ESCU: Linux Auditd System Network Configuration Discovery 4+ distinct recon commands (ip, ss, netstat, arp…) in 15 minutes

Tuning:

  • Webshell. Change the condition to key=process_creation uid IN (33,48) auid=unset. Allowlist the application's normal child processes, such as sendmail and ImageMagick.
  • Hacktool. Make sure your Sigma pipeline maps Image to auditd's exe field. Check the arguments too, because a script run as sh linpeas.sh shows the shell as the program. Add fscan, chisel, frpc, gost, suo5, gs-netcat and xmrig to the list.
  • Reverse shell. Auditd hex-encodes any argument containing a space, so the sh -c "bash -i >& /dev/tcp/…" that PHP's system() produces arrives as hex. Decode it in the SIEM (with Laurel, or the pack's macro) before matching.
  • Download & execute. Add /dev/shm and /var/tmp. The rule matches the program path, not the command line, so hex encoding doesn't affect it.
  • Discovery. Add the web server user filter (uid 33 or 48), lower the threshold to 2–3, and add id, whoami and uname.

Sysmon for Linux detections

Category Rule What it catches
Webshell ESCU: Web or Application Server Spawning a Shell A web server starting a shell. PHP's system()/exec() always go through sh -c, so this catches almost every webshell command.
Hacktool Sigma: Linux HackTool Execution (a015e032) Known attacker tools by name
Reverse shell ESCU: Linux Shell Pseudo Device Reverse Shell sh/bash/dash/zsh with tcp or udp in the command line
Curl/wget Sigma: Suspicious Download and Execute Pattern via Curl/Wget (a2d9e2f3) sh -c that downloads into /tmp or /dev/shm, the classic webshell dropper
Discovery Sigma: Linux Recon Indicators (0cf7a157) find -perm -4000 (hunting for privilege-escalation binaries), -name .htpasswd

Tuning:

  • Webshell. Add php-fpm* and php-cgi* as parent process names. Allowlist sh -c /usr/sbin/sendmail… (PHP's mail()).
  • Hacktool. Same additions as the auditd version. Match on CommandLine to catch scripts.
  • Reverse shell. Raise to high severity when the parent is a web worker.
  • Curl/wget. The rule matches /curl and /wget, so it only fires when the full path is typed. Add curl and wget (with a trailing space), or most real droppers slip through.
  • Discovery. No tuning needed. It's high severity on its own; make it critical when the web server user runs it.

Logging recommendations

Out of the box, a typical Linux system logs very little. A full Linux logging deep dive is beyond the scope of this post, but here are some options:

Linux auditd. Auditd is Linux's native, kernel-level auditing daemon. It ships with no rules enabled until you configure it. Like an EDR or Sysmon, it hooks syscalls in the kernel to record process executions, outbound connections and file writes, each tied to a user and process tree. It can produce a lot of data, so write targeted rules that send only what you need to your SIEM.

DetectionFlow provides an auditd configuration based on Florian Roth's, with added web server monitoring rules. Get it on GitHub.

Sysmon for Linux. It doesn't replace auditd, but it adds richer telemetry for process command lines and parent processes, and links network events to applications and users.

DetectionFlow offers a custom Sysmon for Linux config. Get it on GitHub.

Process Watcher by Florian Roth. A lightweight eBPF monitor that watches specific high-risk process trees and logs detailed telemetry. Get it on GitHub.

Commercial EDR. CrowdStrike, Microsoft Defender for Endpoint on Linux, SentinelOne and many others offer detailed Linux telemetry.

Conclusion

Patch first. Once your riskiest assets are patched, turn to detection.

LLM-assisted research will keep finding new vulnerabilities, and the window from discovery to public exploit will keep shrinking. But even with novel exploits, attackers still have to use common post-exploitation techniques.

Detections and hunts for those techniques don't depend on a specific exploit. They'll still work when the next vulnerability is disclosed, before anyone has written a signature for it.

DetectionFlow helps security teams build, test and deploy detections like these as code. Join the waitlist for early access.

References

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the core PHP runtime, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. When PHP runs out of memory mid-request, it skips cleanup code and leaves stale data behind. Attackers can use that stale data to leak memory contents or to run code as the web server user without authenticating.

Am I affected by PHP2Shell?

Probably, if you run PHP. The bugs are in the PHP runtime itself, so any PHP application may be affected, including WordPress, Drupal and Joomla. Apache with mod_php is the most exposed, and Nginx with PHP-FPM was also exploitable. Patch to the fixed PHP release first.

How do I detect PHP2Shell exploitation?

Use two layers. First, alert on the exploit's fingerprints in the web server error log: the Allowed memory size of N bytes exhausted ... in Unknown on line 0 fatal error and the Failed to decode session object warning. DetectionFlow's open-source detections cover both. Second, detect what attackers do after exploitation, such as the web server user starting a shell, running recon commands, downloading payloads into /tmp or opening a reverse shell.

What log entries indicate a PHP2Shell attempt?

A PHP memory-exhaustion fatal error that ends in Unknown on line 0 means the request failed before any script ran, which is what the exploit triggers. A single one means an attempt or a scan. Three or more from one host within 15 minutes, or one followed by a Failed to decode session object warning, is a much stronger signal. The session decode warning on its own is worth a medium-severity alert too.

Can a WAF stop PHP2Shell?

WAF and IPS rules from vendors like Cloudflare can block known exploit patterns. But those signatures tend to be fragile and specific to one exploit, and they need TLS inspection. Host and application log detections still work when attackers change the exploit.

Which logs do I need to detect PHP2Shell on Linux?

You need the web server error.log and access.log in your SIEM, plus process telemetry from auditd, Sysmon for Linux or a commercial EDR. Linux logs very little by default, so auditd and Sysmon need a ruleset before they record anything useful.

Join the waitlist