PHP2Shell in the wild: confirmed RCE, probing, and exposed attacker infrastructure

PHP2Shell is no longer just a vulnerability disclosure: independent sensors have confirmed code execution in the wild, and the infrastructure around it was sitting in the open.

A 24 October honeypot investigation links crafted HTTP requests to 35 shells spawned by Apache workers across three vulnerable PHP targets. huntback adds two perspectives the report does not have. Our decoys recorded PHP2Shell traffic before the patch and working payloads after it, and our loot harvesting recovered exploit tooling and post-exploitation-style files from exposed infrastructure, including both of the report's source addresses.

These are different types of evidence. The external report establishes code execution on its targets. huntback's request events show who sent what and when; our decoys do not run PHP, so they cannot show execution. Recovered files show what was hosted on reachable infrastructure when we collected it; they do not, by themselves, prove that those files were used in any particular intrusion.

The vulnerability and the fix

The PHP security team identifies two critical flaws in PHP web runtimes. CVE-2026-109618 involves out-of-memory handling that can leave partially initialised request data for cleanup to process. CVE-2026-109619 involves stale request state being used after its backing memory was freed. Both can permit unauthenticated remote code execution. PHP says web-serving installations are at risk, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed; the demonstrated pre-application-code path makes mod_php especially urgent. (PHP security advisory)

The fixed supported releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older are unsupported upstream, although some vendors may supply backports. Updating the actual runtime used by each web worker is the complete fix.

What the confirmed exploitation report proves

The 0x4D31 report reviewed disposable targets running PHP 8.4.26 under single-worker Apache mod_php, with a 128 MiB PHP memory limit. Its authors correlated target-side packet captures, Apache worker identities, PHP errors and Tetragon process events. The reviewed snapshot contained 35 complete final-stage HTTP requests followed by /bin/sh starts directly parented by Apache. Three shell events came from 15.204.59.70; 32 came from 162.35.99.94. Those are two source-address episodes, not proof of two distinct operators.

The successful traffic used a four-stage pattern:

The report's first confirmed chain began at 15:35:32 UTC on 24 October. A shell started at 15:35:38.673 UTC, and the Apache worker then crashed. Other observed commands ran identity checks or called PHP CLI, curl and wget. Some network calls timed out and some tools were absent, but the parent-child process evidence establishes that the commands reached execution. The report associates the observed chain with CVE-2026-109618; it does not establish use of a separate CVE-2026-109619 path.

An HTTP 200, an out-of-memory error or a worker crash alone is not a successful-exploitation verdict. The decisive observation is the unexpected shell launched by an Apache worker after a matched final request. A crashing worker can also leave that request absent from the completed Apache access log, which is why packet and process records matter.

What huntback's decoys recorded

huntback keeps the full request body for every decoy hit, so we searched for the field the exploit is built around, PHP_SESSION_UPLOAD_PROGRESS, rather than for a CVE label or a user-agent. Our 23 October analysis found 110 upload-progress POSTs from three sources between 21 and 23 October; a search on 25 October found two more:

The dropper is the important row. The external report's shells ran proof commands; 77.90.185.20 was already sending a payload built to install a miner, about 30 hours after the release and well before the first confirmed shell on 24 October. We found no events from the report's two source addresses in our decoy data, which describes our sensor set; it does not contradict observations on 0x4D31's separate sensors.

The missing piece: huntback's recovered loot

huntback also scans attacker-side infrastructure and harvests what operators leave in exposed directories and panels. A search of that collection for php2shell returned 84 files. That is a set of filename and content matches, not 84 distinct attacks or 84 validated exploits. Several clusters stand out:

The search returned files from six additional IPs: 45.115.26.30, 204.168.225.59, 31.128.39.24, 41.223.30.7, 54.169.109.7 and 58.221.60.160. 41.223.30.7 hosted PHP2Shell reference material and a copy of the murrez PoC tree, collected on 22 October; seven of its file hashes are identical to copies on 31.56.228.136, so these are mirrors or shared files, not independent exploit families. 31.128.39.24 hosted five PHP2Shell scanner, race and trigger scripts, collected on 23 October, whose previews claim authorised bug-bounty use. 54.169.109.7 exposed three local test helpers, and 58.221.60.160 exposed two Python 2 verification or probe scripts. 204.168.225.59 yielded only a lab log. The 45.115.26.30 item is an index.php whose preview resembles a multipart request body; its automated webshell label is not enough to conclude that a working webshell was deployed there. None of these six IPs is a confirmed-RCE source in the 0x4D31 report.

The recovered sh.php has SHA-256 eb6eec59468d83d4f3a80d98a567a3616bf9709e736615f5c9d7f848a51b6962; the recovered stager.sh has SHA-256 c9216d9d45d0c1b11af23df7e66f4f5cd6fc252076e98192ea52d617c6dccf30. These are file identifiers, not reliable standalone detection rules. A recovered file can be renamed, changed or hosted by a party other than the one who sent the observed requests. The shared IP is a strong lead for investigation, while the packet-to-process evidence remains the basis for calling the honeypot activity confirmed RCE.

The loot search also shows why indiscriminate keyword counts mislead. A CVE-identifier query hit unrelated files that merely contain the identifier, including exposed Git metadata and reports. Source content and automated labels are investigative clues; neither is independent verification of an exploit claim.

Putting the timeline together

Read together, the three sources describe a fast cycle: probes before the patch, a miner dropper about 30 hours after it, public exploit kits on exposed hosts from 22 October, confirmed shells on 24 October, and post-exploitation-style files on one of the confirmed sources a day later. Each step is documented by a different kind of evidence, and each keeps its own limits.

A misleading repository in circulation

The 0x1c1101/CVE-2026-109618-PoC README describes a partial reproduction, says it does not establish reliable code execution, and then states outright that it is fake. Its usage instructions also point to a poc/ directory, while the repository contains an exploit/ directory instead. It should not be used to validate exploitability or build a signature. For the vulnerability and patch state, use the PHP advisory; for the observed execution, use the packet-to-process report.

Defensive priorities

1. Patch the PHP runtime used by every web worker. Inventory containers, appliances, hosting images and vendor packages as well as directly managed servers, and confirm the running worker version after restart. The PHP advisory and CISA call for immediate updates.
2. Correlate network and host telemetry. Hunt for large or high-part-count multipart requests, PHP startup memory errors (Unknown on line 0), unusually large session cookies and worker crashes. The confirmed chains sent no User-Agent, used a multipart boundary of ten C characters, and began with a POST carrying five numbered q...=v query parameters. Escalate when an Apache or PHP worker launches a shell, identity utility, scripting runtime or download tool: a single request marker is a lead, while process parentage and a linked request sequence are much stronger evidence.
3. Pivot carefully on the recovered infrastructure. Check historical connections to the addresses below and the file hashes in endpoint or proxy records. Treat hits as leads that need context; do not infer that a file was deployed merely because it was hosted on an IP that also sent exploit traffic.
4. Use temporary controls while patching. PHP documents request-size and multipart limits and configuration measures for specific attack paths. They reduce exposure but do not replace an updated build.

Indicators

The combined picture is clearer with the loot included: independent sensors documented PHP2Shell requests reaching shell execution, huntback's decoys captured probing before the patch and a miner payload after it, and huntback recovered tooling and post-exploitation-style files from exposed infrastructure, including both confirmed source addresses. Those findings reinforce the urgency to patch, while their different evidentiary limits keep the analysis defensible.

Sources

• 0x4D31: PHP2Shell exploitation observed, packet-to-process RCE evidence (24 Oct 2026)
• PHP: security advisory and fixed releases
• CISA bulletin
• huntback: PHP2Shell probes hit decoys hours before the security release (23 Oct 2026)

Related research

• PHP2Shell probes reached decoys hours before the security release 2026-10-23
• Beyond the backup server: inside an AhsayCBS cryptomining playbook 2026-10-24
• A Week After Censys: Coruna Infrastructure Moved, and Its Staging Host Exposed a Second Offensive Workspace 2026-10-15

Live data

• Live finds: malware, C2 and open directories on the network now
• CVE intelligence: what is being exploited on the decoys