PHP2Shell is no longer a theory: honeypots just caught real shells
for five days the comforting line was “millions of attempts, zero confirmed code execution.” that line is dead. over the weekend a honeypot operator watched attackers chain PHP2Shell into working shells, a public exploit cracked a bitcoin CTF running stock PHP 8.4.26 in under four hours, and a threat intel shop says a suspected north korean crew is quietly sorting through 216 hosts that still look unpatched. if your PHP box is still on the old build, the sloth is not being dramatic. it is being on time for once.
what the honeypots actually saw
Adel Karimi, detection and response lead at Perplexity, runs honeypots that look like ordinary PHP pages on PHP 8.4.26, Apache mod_php, single worker. his first day of data was the boring kind: 30 out-of-memory errors, 11 worker crashes, no code execution. then on October 24 his sensors logged 35 shells across three honeypots from two IP addresses, one IP accounting for 32 of them. the chain was four stages of plain HTTP: requests to exhaust PHP memory, requests to leak memory, then the request that runs a shell command. the leak was not cosmetic. per his write-up, the response carried an 800 KiB decoded cookie dump, and a function address computed from that dump using the public exploit’s offsets shows up in the next execution payload. that is the receipt that turns “suspicious crash” into “confirmed RCE.” Marcus Hutchins of Expel called it the highest quality confirmation of in-the-wild exploitation he had seen so far. no second-stage download was observed.
Karimi was careful, and so are we: this proves the chain works on the intentionally favorable single-worker mod_php profile. it is not a reliability number for other worker counts, PHP builds or apps. which is a nice caveat right up until you remember how many shared hosting boxes are exactly that boring default.
the CTF that settled the argument
security researcher James Pavur stood up a “Steal My Bitcoin” capture-the-flag on Saturday: a standard PHP 8.4.26 server with a crypto wallet on it, and the rule that the winning exploit had to be a single standard-library Python file. on Sunday at 15:47 UTC (8:47 AM PT), UK pentester Jaydip Modhwadia, KillaBoi on GitHub, popped it and took about 0.025 BTC, roughly $2,000. Matthew Hickey summed it up: the exploit is public, it needs a few server-side conditions, and those conditions exist in production. game over, patch.
the campaign angle, with honest error bars
Cyfirma says it has watched a closed I2P channel since October 22 where two operators coordinate PHP2Shell targeting. on October 24 they reported 216 hosts that looked unpatched or only partly mitigated, checked from 21 scan nodes that rotate and stay low and slow, so a rate-based alert will probably sleep through it. Cyfirma ties it to the Lazarus family with moderate confidence, based on language and habits, not shared malware or infrastructure, and says a Korean-speaking criminal crew would fit too. listed priorities are government and banks, then logistics, ports, aviation, manufacturing and trading platforms. no victims named, no confirmed mass compromise. the useful detail: the operators drop any host that banners a fixed version or sits behind heavy filtering. a current version string is a cheap way to get skipped.
the correction that matters for your stopgaps
early coverage, ours included, leaned on the session upload-progress field as the trigger story. per PHP’s advisories, upload progress belongs to CVE-2026-109619 only. CVE-2026-109618 is the out-of-memory corruption path, and turning off session.upload_progress.enabled does nothing for it. Datadog also says the community mitigations do not fully protect you. stopgaps like a low post_max_size and filtering huge multipart bodies at a reverse proxy buy time. they do not replace the patch.
what to do today, in order
- patch: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.1, 8.0 and 7.4 only get source backports, and cPanel EasyApache, CloudLinux, TuxCare and Plesk ship their own builds, so confirm with your vendor. 5.4 through 7.3 has no fix: migrate or isolate.
- restart every worker. a reload that keeps old workers alive keeps the stale state alive.
- if you think you were hit, capture memory and logs before you patch, because a restart wipes the 109619 state. then rebuild from a trusted image and rotate every secret the PHP worker could read.
- isolate anything internet-facing you cannot patch within hours, starting with Apache mod_php.
- turn off
expose_phpand stop bannering versions. it is not a fix, but nobody needs to read your version off a header.
how to hunt it
application logs will usually show nothing. look for a PHP or web server process spawning something it never spawns (sh, bash, id, curl, wget, nc), bursts of “Allowed memory size” errors and worker segfaults, oversized multipart POSTs to pages that never take uploads, new PHP files in web roots, and new cron jobs, local users or SSH keys. hunt back to October 17, when AWS saw the first attempts, and use long windows. CISA’s alert carries a Sigma rule, and Cyfirma published Sigma, Splunk and YARA content with defanged scan-node addresses. some of those nodes are described as compromised machines that may belong to victims, so check for prior contact before you assume who owns them.
a quick warning about “free PoCs”
researchers flag that some PHP2Shell proof-of-concept repos floating around are fake and may carry malware. if you are testing, test your own lab, use code from people you can name, and read it before you run it. the sloth has seen too many “exploit.py” files that exploit the person running them.
sloth take
the internet spent five days arguing about whether PHP2Shell was “really” exploitable, and the honeypots, a CTF and an I2P chat log answered in one weekend. the pattern never changes: “no confirmed exploitation” is a timestamp, not a risk rating. if a PHP box is still on 8.4.26 tonight, the question is not whether someone will try. the question is whether you are one of the 216.
sources
- BleepingComputer, “PHP2Shell security flaws now successfully exploited in the wild” (October 26, 2026)
- SecurityWeek, “PHP2Shell Exploitation Moves From Probes to Working Shells” (October 26, 2026)
- GovInfoSecurity, “Honeypots Now Recording In-the-Wild PHP2Shell Exploits” (October 26, 2026)
- Security Affairs on Cyfirma’s suspected North Korean PHP2Shell campaign (October 26, 2026)
- CISA alert “Critical Vulnerabilities in PHP Require Immediate Patching” (updated October 23, 2026)
- Wiz Research PHP2Shell disclosure; Datadog Security Labs and Rapid7 analyses; PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 release notes
