PHP2Shell Moves From Probing to Proven: A Honeypot Has Caught Working Remote Code Execution. How the Week Unfolded, and What to Check Today
For days, every PHP2Shell attack anyone could document had failed. That changed this weekend, when a researcher’s honeypot recorded a confirmed remote code execution against an unpatched Apache and PHP 8.4 setup. Here is the week in order and the checks that matter now.
Since the two PHP2Shell flaws became public, defenders have had one small comfort: the attack traffic hitting the internet looked noisy but ineffective. Scanners were busy, published exploits mostly did not work, and nobody could point to a confirmed break-in. That comfort is gone. Security researchers now say they have solid evidence of the bugs being used to run code on a server in the wild.
BleepingComputer reported the confirmed exploitation on Monday. Additional context on scanning activity and detection advice comes from The Hacker News’ running coverage of PHP2Shell attacks.
The week in order
- Before the patch: Amazon Threat Intelligence says attackers were already going after the flaws four days before fixes shipped. Cloudflare, Hadrian, watchTowr, Previdian and Patchstack all saw attempts ahead of public disclosure, and all of them judged those attempts unsuccessful. Details and proof-of-concept code leaked early, but the PHP security team said none of it worked.
- Tuesday, October 20: The PHP security team told administrators to get ready to install updates as soon as they appeared.
- Wednesday, October 21: Fixes for CVE-2026-109618 and CVE-2026-109619, the pair known as PHP2Shell, were released.
- Thursday, October 22: ReliaQuest reproduced CVE-2026-109618 in a lab and published the trail it leaves: a POST request that returns a 500 error, PHP logging memory exhaustion and heap corruption, and the Apache worker that handled the request crashing.
- Friday, October 23: The PHP team published a workaround for a third, unpatched remote code execution bug, CVE-2026-115560, which only applies to an unusual mix of configuration and application code.
- In the following days: CYFIRMA reported a low-and-slow scanning campaign from 21 compromised nodes against 216 unpatched or partly mitigated hosts in the U.S., Asia, the Middle East and Europe, which it ties with moderate confidence to an operator linked to North Korea’s Lazarus Group. On October 25, Defused Cyber said PHP2Shell probes were also hitting its Palo Alto GlobalProtect honeypots, apparently to build a target list.
- By Monday, October 26: Adel Karimi, detection and response lead at Perplexity, shared evidence from his honeypots of confirmed remote code execution against Apache with mod_php running PHP 8.4.26. Expel researcher Marcus Hutchins called it the highest-quality confirmation of in-the-wild exploitation he had seen.
Why this confirmation is different
Earlier reports of “successful” attacks were hard to separate from crashes and guesswork. Karimi says this capture is different: the server’s response leaked about 800 KiB of memory, a function address worked out from that leak with the public exploit’s offsets showed up in the attacker’s next payload, and the shell command ran about 1.6 milliseconds after the final request. In plain terms, this was not just a crash followed by something suspicious. The exploit worked from start to finish.
Until this capture, Dataminr’s threat research team described the activity it had seen as scanning, fingerprinting and exploits that did not work, with no known compromises.
What is still unclear
- The confirmed case was a researcher’s honeypot, a deliberately exposed decoy, not a named victim. How many real servers have been taken over is not known.
- Palo Alto Networks’ Unit 42 has withdrawn its earlier statement that an attack on a European government agency began with PHP2Shell. It now says it cannot confirm which flaw was used for initial access.
- The North Korea link rests on CYFIRMA’s analysis and is rated moderate confidence.
Checks for today
- Make a list of every system you own or rent that runs PHP: websites, client portals, online stores, internal tools, and appliances with a web console.
- Confirm with your host, developer or vendor that PHP itself has been updated on each one. Bitsight points out that changing application code, adding a web application firewall rule or updating a plugin does not remove a flaw in the PHP runtime.
- If an update is delayed, ask your provider about the interim mitigation the PHP team recommends, which turns off PHP’s session upload progress feature.
- Ask whoever reads your server logs to look for the ReliaQuest pattern: a POST that ends in a 500 error, memory exhaustion and heap corruption messages, and a crashed web worker.
- Treat any server that shows that pattern and was unpatched as possibly compromised, and check it for new files, new accounts and outbound connections.
What this means for your company
PHP runs a large share of the web, and many small businesses rely on it without knowing it, through a WordPress site, a hosted shop or a portal a vendor built years ago. The question is no longer whether these flaws can be used against a real server. The question is whether your servers were updated before someone tried. If you cannot answer that for every site and appliance you depend on, start with the inventory above and get written confirmation from each provider.
Need help finding every PHP system you depend on and confirming that each one is patched? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
