Adel Karimi's Honeypots Caught 35 Working PHP2Shell Shells on Unpatched PHP 8.4.26, and Each One Followed the Same Four Multipart Requests Defenders Can Hunt For

LONDON - For most of the three days after PHP shipped emergency fixes for the PHP2Shell flaws, one researcher's decoy web servers recorded noise: crashed workers, memory errors and exploits that did not work. On the afternoon of Oct. 24 they recorded something different. An Apache worker started a shell.

Adel Karimi, detection and response lead at Perplexity, published what he calls packet-to-process evidence of 35 successful remote code executions against three honeypots running PHP 8.4.26 under Apache mod_php, one release behind the fixed 8.4.27. Each case ties a captured HTTP request to a /bin/sh process that the Linux monitoring tool Tetragon recorded as a direct child of an Apache worker running as the web user, uid 33. BleepingComputer reported the findings on Monday, and Expel researcher Marcus Hutchins, in comments cited by the publication, called it the highest-quality confirmation of in-the-wild PHP2Shell exploitation he had seen.

Karimi also shared a detail that separates this from the crash reports that came before it: the shell command ran about 1.6 milliseconds after the final captured byte of the execution request, BleepingComputer reported.

Two addresses, one exploit template

The report groups the activity into two episodes by source address, and it is careful to say that is not attribution. The first, 15[.]204[.]59[.]70 on OVH US hosting, produced three shells on the first decoy, the first at 15:35 UTC. The second, 162[.]35[.]99[.]94 on Interserver, produced 32 between 16:46 and 18:57 UTC: 19 on the second decoy, 10 on the third and three on the first.

The first three request bodies were byte-for-byte identical across both episodes, which links them to the same exploit template but not to the same operator, Karimi writes. The traffic closely matches a public proof-of-concept that uses leaked memory to work around address randomization, and the chain is consistent with CVE-2026-109618; the records do not show use of a separate CVE-2026-109619 path.

Four requests before every shell

Every successful chain was a sequence of HTTP/1.1 multipart POSTs to / or /index.php, with no User-Agent header and a multipart boundary of ten C characters, and every execution request arrived over plaintext HTTP on port 80. The first request, about 1.06 MB, exhausted the decoys' 128 MiB PHP memory limit and produced a fatal error ending in "Unknown on line 0," meaning no application script was running. The second, about 33.1 MB, came back with a session cookie that decoded to 819,200 bytes of leaked memory. A third request of 279,369 bytes forced another out-of-memory error, and the fourth, 451,384 bytes, carried the payload adjusted to that target's leaked addresses, followed by the shell.

Karimi warns against the shortcuts a SOC might take. The first three requests can return HTTP 200, and the final one often crashes the worker after the shell starts, so there may be no completed access-log line for the request that did the damage. A memory error, an oversized PHPSESSID or a worker crash alone does not prove execution, he writes. The decisive signal is the unexpected shell with an Apache parent.

Apache logged 52 cookies of the disclosure size across the three decoys, and 51 complete responses were reconstructed in the packet captures and acknowledged by the client.

What the shells did

The commands were proofs, not payloads. The first episode wrote the output of id to a temporary file, tried to write it to web roots and called wget, which failed because the decoy's file system was read-only and wget was not installed. The second cycled through PHP's command-line interpreter, curl and wget to call back to the attacking address on ports 8080 and 80, later putting the server's user name, host name and architecture into the callback URL. Karimi found no downloaded second stage in the evidence.

He also notes the limits of the setup. The decoys used a single Apache worker and plaintext HTTP, a favorable profile for the exploit, so the results say nothing about reliability against other worker counts, PHP builds or applications.

The same six sensors had seen no code execution earlier in the week. A companion report covering Oct. 22 to the early hours of Oct. 24 counted 30 pre-script out-of-memory errors and 11 worker crashes over about 26 hours and 43 minutes, with no remote code execution or usable memory leak confirmed in that window.

What detection teams can hunt for

• A web server process (apache2, httpd or a PHP worker) starting /bin/sh or sh as the web user, especially followed by id, php -r, curl or wget making outbound connections.
• The request sequence in web and network logs: a chunked multipart POST of about 1 MB, a chunked multipart POST of about 33 MB, a fixed-length multipart POST of about 279 KB and a fixed-length multipart POST of about 451 KB, in that order from one source, with no User-Agent.
• PHP fatal errors reading "Allowed memory size ... exhausted ... in Unknown on line 0" near unusually large PHPSESSID values in responses, and Apache child processes exiting on segmentation faults.
• Multipart bodies that carry PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS fields; the report publishes SHA-256 values for the fixed A1, B1 and A2 bodies and for each execution body.
• Traffic from 15[.]204[.]59[.]70 and 162[.]35[.]99[.]94, the two confirmed sources, and from 104[.]28[.]208[.]84 and 144[.]48[.]4[.]242, which Karimi lists as attempt indicators only, with no shell observed.

The fix remains the update: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For servers that ran an older build after Oct. 21, the honeypot data argues for checking process telemetry for Apache-parented shells rather than relying on HTTP status codes or a single error line.