php2shell: a public exploit is out, the patch still stops it

Yesterday we published our php2shell lab: how we reproduced the PHP engine RCE in a sealed box and proved it, with the offensive detail held back. Today the picture moved enough to be worth a second note. A public exploit for the same flaw is now on Exploit-DB, and three intelligence teams published real-world activity, including one successful compromise. Here is what we checked, what is genuinely new, and what it means for patching. [Confirmed]

A public exploit, and what it actually is

On 22 October an entry for CVE-2026-109618 was published on Exploit-DB as ID 52704, listed under OffSec and crediting the original work to a researcher handle, with a note that the code was adjusted using AI. [Confirmed] One detail is easy to misread: the listing's own "Verified" field is marked with a cross, not a check. It is a published proof of concept, not something Exploit-DB or OffSec have independently verified, and we are careful not to describe it as validated by them. [Confirmed]

A public, easy-to-obtain exploit changes the risk arithmetic even when the underlying bug is unchanged: more people can now run it, with less skill, against more targets. [Our assessment]

We ran it, in the same sealed box

We took the file exactly as published, read it before running anything, pinned it to one target URL and two fixed commands, and ran it against our isolated lab: PHP 8.4.26, Apache, mod_php, on a Docker network with no route to the internet. In three runs it reached code execution as the web user every time, and our harness confirmed it the honest way. It refuses to call a run a success unless the exact output of id for the web user, uid=33(www-data), lands in a marker file that it cleared first. The proof is the measured effect, not the exploit's own message. [Confirmed]

The comparison is the real finding. We diffed this exploit against the PoC we used yesterday, definition by definition. The exploitation core, the request builder, the two memory leaks and the cookie parsers, is identical down to the parsed syntax tree. [Confirmed] What changed is everything around it: the entry point was rewritten, the target list and the built-in listener were stripped out, and, most usefully, it now re-reads its own proof of execution after each attempt instead of printing a blind success. The earlier code reported BLIND_OK without ever checking whether a command had run. [Confirmed] This is not a new vulnerability or a new technique; it is the same chain, packaged to be more convenient and more honest about whether it worked. [Our assessment]

The patch still holds

We re-ran the public exploit against the fixed release and two stopgap configurations, with the same harness. The result matched our earlier lab exactly:

Read the last three rows carefully. Each means only that this exact chain did not reproduce in that configuration, not that a host is safe. [Our assessment] They hold for one public chain and one build. PHP is explicit that updating is the only complete fix; the two configuration changes each cut a single path and are stopgaps, not remedies. [Confirmed]

The activity is real now, not hypothetical

Three teams published findings worth folding into your hunt, each with its own scope.

• Amazon (MadPot). Amazon's honeypots logged an exploitation attempt on 17 October, four days before public disclosure, and more on 21 October from different infrastructure. Amazon describes php2shell as broadly exploited while noting it is unclear whether those attempts would have succeeded on real systems, and recommends hunting back to at least 17 October rather than from the advisory date. [Confirmed]
• Sophos. Sophos reported multiple attempts and one successful exploitation, which wrote a file to /tmp and ran it (./nfs php) with a payload that looks like a Mirai variant it calls "potassium"; at the time of its update Sophos had not linked the activity to ransomware, data theft or supply-chain abuse. Those indicators belong to Sophos's incident, not to every php2shell attempt. [Confirmed]
• Datadog Security Labs. Datadog reproduced the RCE independently and added three defensive points: application authentication does not help, because PHP processes the request before your application code runs; its path for CVE-2026-109618 uses application/x-www-form-urlencoded, so a defense limited to multipart or PHP_SESSION_UPLOAD_PROGRESS does not cover every route; and a successful run can return HTTP 200 without crashing the worker, so the status code and the absence of a crash do not rule out execution. [Confirmed]

Do this week

A public exploit is a deadline, not a verdict on your servers. That it ran in our lab says the chain is real and now easy to obtain; it does not say it is reliable against your build, and a scan that fails proves nothing. [Our assessment] Patch first. Then, if you want to know whether anyone reached you before you did, that is what a compromise assessment and threat hunting are for; if you want the detections above tuned to your stack, that is detection engineering; and the lab discipline behind this post is how we run a red-team engagement. The full technical write-up stays under NDA, for the same reason it did yesterday: inside our php2shell lab explains why.