Security researcher Adel Karimi, who leads detection and response at Perplexity, has published packet-level evidence that the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) are being exploited to run commands on real web servers. BleepingComputer reports that Marcus Hutchins of Expel, who has been tracking many alleged exploitation reports, called it by far the highest-quality confirmation of in-the-wild exploitation he had seen. Earlier activity reported by Cloudflare, Hadrian, watchTowr, Previdian and Patchstack had been flagged as unsuccessful, and Dataminr said until now it was limited to scanning and non-working exploits.
According to Karimi’s report, his sensors correlated 35 complete execution-stage requests with 35 shell processes started directly by Apache workers, across three honeypot servers running PHP 8.4.26 under Apache mod_php. The traffic came from two source addresses and followed a four-stage chain: memory pressure, a memory disclosure through an oversized session cookie, more memory pressure, then an execution request adjusted to the leaked memory addresses. The report says this matches the publicly known exploitation technique rather than a new one, and that the packet evidence does not identify the exact tool used. These were disposable honeypots, so no real organisation’s compromise is described. For the fixes, the earlier timeline and the separate, unpatched third flaw, see our posts on the patch release, Amazon’s early-exploitation findings and CVE-2026-115560.
How to check if you’re affected
Affected versions are PHP installations older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 within their release branch (see our patch-release post for the full list). Check with php -v or your hosting panel, and check PHP inside container images as well; the honeypots that were hit ran 8.4.26, one release before the fix.
- Update to a fixed release; Amazon said earlier that upgrading is the only complete remediation for both CVEs.
- For the separate, unpatched CVE-2026-115560, the PHP team advises setting
session.upload_progress.enabled=0until a patch ships, per BleepingComputer. That setting was also recommended before the PHP2Shell patches were released. - Karimi’s evidence is published in a public GitHub repository with the packet captures and process records for all 35 confirmed shells, which defenders can compare against their own logs.