Update Oct 26: CISA has added both flaws to its Known Exploited Vulnerabilities catalog with a federal deadline of Oct 29. See the KEV item.

Until now, public reports of PHP2Shell (CVE-2026-109618/109619) activity described scanning, crashes and non-working exploits. A report published Oct 24 by Adel Karimi (detection and response lead at Perplexity) is the first to tie exploit traffic to code execution with packet and process evidence. Expel's Marcus Hutchins called it "by far the highest quality confirmation of in-the-wild php2shell exploitation" he has seen.

• What was seen: 35 complete execution-stage POSTs matched to 35 /bin/sh processes started directly by Apache workers (uid 33) on three disposable honeypots running PHP 8.4.26 under single-worker Apache mod_php, on Oct 24 UTC.
• Two source clusters: 15.204.59.70 (OVH US, 3 shells) and 162.35.99.94 (Interserver, 32 shells). The report says that is two address clusters, not proof of two actors.
• Technique: a four-request chain (memory pressure, an 800 KiB PHPSESSID memory leak, more pressure, then a target-adjusted execution request) that matches the public leak-guided ASLR-bypass PoC family and CVE-2026-109618. Nothing showed a separate CVE-2026-109619 path, and the targets were unpatched, so this is not a patch bypass.

Honeypots are built to be hit. This proves working exploits are in use, but it does not confirm that a real organization was compromised. Do: make sure every PHP worker actually runs 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or later (or a distro backport), restart workers, and hunt from Oct 17 (see the new hunt and the main PHP2Shell item).