PHP2Shell is the name for two critical flaws in the PHP runtime that let an unauthenticated attacker run code on servers that serve web requests. The PHP security team released fixes on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Honeypot data published on October 24 reported 35 cases of confirmed remote code execution, based on evidence linking malicious web requests to shell processes running under the web server's account.The vulnerabilities affect the PHP runtime itselfApplication-level protections should not be treated as a substitute for applying the relevant security fixes.. Organizations should identify internet-facing PHP deployments and verify that the relevant fixes have been applied, including vendor-provided backports where applicable.
In this article, the focus is how the published packet-to-process evidence establishes real code execution, how the four-stage request chain works, and why a compromised server can still look healthy in standard logs. The closing section covers how teams can locate every PHP runtime they operate, including copies bundled inside third-party products.
1. How the honeypot data proved real execution
An earlier capture window on the same sensors recorded only out-of-memory errors and crashed workers, with every malicious request still returning HTTP 200. The report is explicit that a status code alone was not a reliable sign of success. The confirmed cases rest on a different signal. For each one, the sensor tied a completed execution-stage request to a /bin/sh process started directly by an Apache worker running as the web-server user. Several shells then spawned their own child processes, such as id and curl, which the sensor recorded by process lineage rather than by any log message.
2. The four-stage request chain behind each shell
The reviewed targets ran PHP 8.4.26 under single-worker Apache mod_php. Each successful attack used four multipart POST requests in sequence. The first exhausts the PHP memory limit during request startup, before application code runs. The second returns an oversized PHPSESSID cookie of about 819,200 bytes that leaks aligned, pointer-like values from process memory. The third applies more memory pressure. The fourth carries the execution payload, adjusted for each target using the leaked addresses, and produces the shell. Matching the leaked pointers to the execution request across three separate targets showed the attacker calculating around each host's randomized memory layout rather than reusing one fixed address.
3. Compromised PHP servers can look healthy in logs
The relevant PHP errors appeared during request startup as "Unknown on line 0", before application code ran, which is consistent with an engine flaw rather than a CMS bug. A worker often crashed with a segmentation fault right after the shell started, so the final request left no completed access-log entry. Independent research on the same flaws describes the same pattern, where workers stay stable, responses return HTTP 200, and application logs record nothing because no application code executes. Detection therefore moves to the host. The published commands wrote id output to proof files and reached back to attacker servers with curl and wget, the kind of child process that follows a stealthy local file compromise defenders are advised to watch for.
4. Finding every PHP runtime in the estate
The observed activity came from two hosting-network source addresses using closely related tooling that matched a public exploit, which the report notes does not establish shared control. The wider exposure is large, since one census counted millions of internet-facing PHP services with most on unsupported branches. PHP also ships inside appliances and containers, so patch status has to come from the package version and the vendor advisory rather than assumption. An external vulnerability assessment and penetration testing engagement maps the exposed attack surface, identifies the runtime behind each service, confirms whether fixes reached production, and retests after remediation.
PHP2Shell is no longer a theoretical risk or a set of failed probes. The published evidence shows unauthenticated requests reaching a shell on vulnerable servers, with little trace left in ordinary logs. Organizations that know where PHP runs and can verify the patched version on each host close that window fastest, and the internet-facing estate is the place to start.
If you're looking to assess your organization's exposure to similar risks, Scan your organization's exposure, explore Laburity, or book a consultation.
