PHP2Shell one week on: inside two operators' exploit labs

A week after PHP patched PHP2Shell, the most useful evidence is not another shell on a sensor. It is the operators' own notes, left open on their servers, saying exactly which PHP builds their chain breaks.

huntback runs decoys that record what attackers send, and it scans the infrastructure those attackers use, collecting what they leave exposed. For PHP2Shell that second source has been the richer one. Since 22 October we have recovered exploit kits, Docker labs, target lists and lab notebooks from seven hosts. This post covers the two most revealing workspaces, what they say about which systems are really at risk, and what our decoys saw at the same time.

We keep the evidence types apart. Decoy events show who sent what and when. Recovered files show what was exposed when we fetched it. Notes inside those files are the operators' own claims about their own labs, and we report them as claims.

Seven hosts in eight days

When a source probes our decoys, or when a file we recover names other infrastructure, huntback scans those hosts and collects what is exposed. For PHP2Shell that produced:

The first five were in our 25 October report. The kits on the first two hosts predate the first confirmed shell in the wild, on 24 October, by one to two days. Several files repeat across hosts byte for byte, so these are shared kits passed between operators, not seven independent exploits.

The handoff file in the agent workspace also cites an evidence folder from a kit called 9bie-php2shell, on 22 October at 15:23 UTC. Ready-made exploit kits were changing hands within a day of the patch.

An AI agent's lab notebook: ten builds, full RCE

The workspace on 209.99.184.246:8099 is organised for coding agents: an AGENTS.md, per-round prompts, a turn plan, a watchdog and handoff files between agents. Its notes are written in Polish. Most of it concerns unrelated research against cryptocurrency and gaming platforms, which we do not describe here. Eight notes, a profile file and six scripts cover PHP2Shell.

The handoff to the agent called code2 sets the rules plainly: local Docker only, no external targets, and a strict definition of success. A first-stage heap leak or an "armed" upload does not count. Only a file containing the output of id does.

Our summary of the handoff rule: "full proof" means a file holding uid=... from running id; stage 1, "Armed" or a cookie leak is not proof.

The status file, timestamped 22 October 17:40 UTC, reports seven builds with full RCE. An update appended the same day, after another seventeen work blocks, raises that to ten of thirteen and adds working recipes for 8.4.10, 8.1 and 8.0. Combined and translated:

Three details stand out.

• Exact offsets per build. Each working row records the build-specific address of zif_system and the hash table offsets it needs. A chain this precise suits stock distribution packages; a custom or hardened build changes the numbers until someone recalibrates.
• The agent separated real proof from false positives. Its lab file records that the "armed" monitor also fired on a fixed 8.4.27 build, and marks that as a false positive not to be trusted. Defenders should apply the same rule to their own detections: an upload-progress request is attempt evidence, a web worker starting a shell is execution.
• The mitigation was tested. With session.upload_progress.enabled = Off the lab could not arm the bug at all.

The patch-analysis notes compare the PHP source between 8.2.34 and 8.2.35 and between 8.4.26 and 8.4.27. The agent's reading is that the fixed builds reset session state at the start of a multipart upload, which removes the state the chain depends on.

PHP 8.0 and 8.1: a working chain and no patch

PHP's fixed releases cover 8.2 to 8.5. The 8.0 and 8.1 branches are out of support and got no PHP2Shell fix. An early coverage note in the same workspace records the chain failing on 8.0.30 and 8.1.34; by the end of 22 October the agent had a working recipe for both.

That matters most for appliances, which embed their own PHP and update it on the vendor's schedule rather than PHP's. PwnDefend reported on 30 October that around 20 to 25 Palo Alto firewalls may have been compromised through PHP2Shell, with at least one confirmed. We cannot link the operators behind those intrusions to this workspace. What the notes do show is that the oldest PHP branches were already exploitable in an operator's lab on 22 October. If a device embeds PHP 8.0 or 8.1, no PHP release fixes it. Only the vendor's update does, and until then its management interface should not be reachable from the internet.

A kit tuned for one build, pointed at real sites

The 1,563 files (about 1.2 GB) on 96.126.130.81:9999 are commented and labelled in Chinese. The PHP2Shell material is a small, focused set:

PHP 8.4.26 on single-worker Apache mod_php is also what the vulnerable targets ran in the 24 October confirmed-RCE report. Prefork gives the chain a small, predictable set of worker processes to cycle through, which is the likely reason the kit is built around it.

We searched all 221 log and text files in the workspace for an id result and found none. This is preparation against named targets, not evidence of compromise.

What our decoys saw

huntback's decoys recorded 227 PHP2Shell requests from six sources between 21 and 28 October. The first two arrived at 08:41 and 08:44 UTC on 21 October, before the release, as we reported at the time. The heaviest source, 77.90.185.20, sent 106 requests carrying a RedTail-style miner dropper. The most recent, on 28 October, introduced itself as php2shell-range/1.0 (authorized security testing).

That is a modest volume for a critical PHP bug, and it fits what the operators' notes say: the reliable chain needs a known build, a known server model and many requests per target. It suits targeted use more than internet-wide spraying.

Palo Alto fingerprinting

Requests for PAN-OS management and GlobalProtect paths reach the decoy network every week:

Since 21 October the most requested paths were the GlobalProtect login.esp and prelogin.esp pages, /php/login.php on the management interface, a source map under /php/ztp_gate.php, and /sslmgr. That is fingerprinting: finding which hosts are Palo Alto devices and which expose management. The busiest week was the one PHP2Shell went public. None of these requests carried a PHP2Shell upload, which suggests the exploit was kept for devices already confirmed by this kind of survey.

Limits of this evidence

• The uid=33 results come from the operators' own lab, as they report them. We have not reproduced them.
• No file we recovered shows PHP2Shell code execution on a real, third-party system, and our decoys do not execute PHP.
• Exposed tooling proves the tooling existed on that host when we fetched it. It does not prove any particular target was hit.

What defenders should do

1. Patch to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. The operators' own negative control on 8.4.27 shows the fix stops the chain.
2. Until then, set session.upload_progress.enabled = Off. Few applications need upload progress, and the lab could not arm the bug with it off.
3. Hunt down PHP 8.0 and 8.1. They have no fix and a working chain exists. Upgrade them, and treat firewalls and other appliances with embedded PHP as needing the vendor's update. Take management interfaces off the internet now.
4. Alert on execution, not on requests. A web server process (apache2, php-fpm, httpd) starting /bin/sh is the signal that matters. Large multipart POSTs carrying PHP_SESSION_UPLOAD_PROGRESS are worth logging, but they are attempts.
5. Look for worker churn. The chain rotates workers by forcing out-of-memory crashes. A burst of PHP memory-limit errors and worker restarts from one source is an early sign.

Indicators

Machine-readable: download these 13 indicators as CSV (type, value, context; values are not defanged).

Machine-readable: download these indicators as CSV (type, value, context; values are not defanged).

These hashes identify files, not behaviour. A renamed or edited copy will not match, so use them to find related material rather than as detection rules.

Sources

• PHP: security advisory and fixed releases
• 0x4D31: PHP2Shell exploitation observed, packet-to-process RCE evidence (24 Oct 2026)
• PwnDefend: PHP2Shell activity update (30 Oct 2026)
• huntback: PHP2Shell in the wild, confirmed RCE, probing and exposed attacker infrastructure (25 Oct 2026)
• huntback: PHP2Shell probes reached decoys hours before the security release (23 Oct 2026)

Related research

• ARTEX learns to spot honeypots: dissecting an AI pentest agent's decoy detector 2026-11-04
• An operator used the pentestcode AI agent against 25 mid-size and large European companies and reports breaching 10 of them 2026-10-31
• PHP2Shell in the wild: confirmed RCE, probing, and exposed attacker infrastructure 2026-10-25

Live data

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