PHP2Shell: What is it and what can your security team do about it?

TL;DR: Two critical flaws in PHP's core (CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2) let an unauthenticated attacker run code on a web server by sending it a request. Patched releases shipped October 21. Patch now, and treat any internet-facing PHP on an unsupported version as exposed.

What is it?

PHP2Shell is the nickname for two memory-safety bugs in the PHP engine itself, not in a plugin or framework:

• CVE-2026-109618: When PHP runs out of memory while setting up a request, it leaves data partly initialized. Cleanup then treats that data as valid, opening a path to code execution.
• CVE-2026-109619: PHP keeps request-specific state after its memory is freed. A later request handled by the same worker can reach that stale state (use-after-free), enabling memory disclosure and code execution.

Why it matters:

• No login needed. PHP says its validated exploit works over HTTP against mod_php with default input and memory limits, and runs before any application code.
• Wide exposure. PHP says any installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. That covers WordPress, Drupal, Laravel, control panels, and many vendor appliances.
• Code runs as the web server account. From there an attacker can drop webshells, steal credentials and configuration, and pivot.
• Disclosure went wrong. Details leaked on October 20, before the coordinated embargo. PHP pulled its release forward to October 21. watchTowr reports exploitation in its honeypots from October 21. Huntress had not yet seen it across its customers at publication, and other vendors reported attacks emerging, including AWS, which claims to have identified exploitation of the vulnerabilities prior to public disclosure. Assume exploitation is happening or imminent.

What should you do?

1. Patch. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and LTS vendors have shipped patches, so check your package source. Restart PHP-FPM, Apache or whatever serves PHP afterward.
2. Inventory. Find every PHP install, including those bundled in vendor appliances, Windows software, control panels and CMS hosts.
3. Handle end-of-life PHP (8.1 and earlier). No official release is planned. PHP published minimal source backports for 7.4, 8.0 and 8.1. Otherwise check whether your LTS vendor backported the fix. As a stopgap, PHP says setting session.upload_progress.enabled = Off in php.ini (then restarting) mitigates the known abuse cases. Take these systems off the internet, or put them behind a VPN or WAF, until they are upgraded.
4. Hunt for compromise on exposed hosts. Look for PHP worker processes (php-fpm, php-cgi, httpd, apache2, w3wp) spawning shells, interpreters or downloading tools. Look for new files in the web root, new cron jobs or scheduled tasks, and new accounts. If you suspect compromise, isolate the host and preserve web and PHP logs before you clean up.

How you can detect this

Detection today means catching what attackers do after code execution, regardless of the entry point. Endpoint detection and response (EDR) and other logging available on web servers may provide sufficient visibility to detect post compromise behaviors related to PHP2Shell. The following pseudo-detectors mostly look for web processes spawning shells and may help organizations defend themselves against exploitation as they work on installing patches:

Web server or PHP worker spawning a shell (Linux)

On Linux systems, look out for web worker processes like apache2, httpd, nginx, php-fpm, php-cgi or lsphp spawning sh, bash, python, perl, ruby, nc, socat, curl, or wget. Web workers rarely do this, so it points to code execution through the web tier.

Web server spawning a shell or download tool (Windows). 

On Windows systems, look out for processes like php.exe, php-cgi.exe, w3wp.exe, httpd.exe, nginx.exe, or similar spawning cmd, powershell, scripting hosts, certutil, bitsadmin, curl, or mshta.

Reverse shell one-liners. 

You can also attempt to detect commands that wire a shell to a remote host, such as /dev/tcp and mkfifo shells and PHP fsockopen shells, which is how an attacker gets hands-on access.

Reconnaissance from the web server. 

Be particularly wary of any web worker process running commands like whoami, id, uname, hostname, or ipconfig as these are the usual first steps after gaining code execution.

We are monitoring

We are tracking vendor advisories and threat intelligence for confirmed exploitation, indicators of compromise and proof-of-concept releases, and will update our detections as they land. Many security vendors have released their own PHP2Shell detections in their products. We will investigate those alerts for our customers. When indicators of compromise are published, we will hunt for them across customer telemetry, looking back as well as forward. If we see activity that matches post-exploitation behavior on a PHP-serving host, we will contact Daylight customers through official channels.

Questions about your exposure? Contact Daylight.

‍