Researchers have recorded PHP2Shell exploitation in honeypot evidence of remote code execution against Apache mod_php running PHP 8.4.26. Emergency fixes for CVE-2026-109618 and CVE-2026-109619 shipped on October 21, after probing that began four days earlier. A third remote code execution bug, CVE-2026-115560, still has no emergency patch.
Key Takeaways
- Honeypots recorded RCE against Apache mod_php running PHP 8.4.26.
- Fixes shipped October 21 for CVE-2026-109618 and CVE-2026-109619.
- CVE-2026-115560 has no patch; disable session upload progress.
- Amazon saw probing on October 17, four days before patches.
What Honeypot Evidence of PHP2Shell Exploitation Shows
BleepingComputer reported that Adel Karimi, detection and response lead at Perplexity, shared honeypot findings of confirmed remote code execution against an Apache mod_php installation running PHP 8.4.26. He shared that the case showed usable memory disclosure, including an 800 KiB decoded cookie dump, rather than only a crash followed by a suspicious process.
“The client acknowledged the full response; the shell command then ran about 1.6 ms after the execution request’s final captured byte,” Karimi shared.
InfoQ reported that remote code execution for both flaws was validated over HTTP against mod_php with default PHP input and memory limits. Marcus Hutchins of Expel called the same case “by far the highest quality confirmation of in-the-wild php2shell exploitation I’ve seen so far,” BleepingComputer reported.
Until Karimi’s findings, Dataminr’s TRACE team described the malicious activity as limited to scanning, fingerprinting, and use of non-working exploits, with no known compromises. The PHP security team said proof-of-concept exploits published before the patches were not functional.
Attempts Started Days Before the October 21 Fixes
SecurityWeek reported that Amazon Threat Intelligence saw the first attempt on October 17, from a commercial anonymization network, while the flaws were still under embargo. How the actor obtained exploit details before disclosure remains unclear.
After the patch, Amazon said PHP2Shell is “now being broadly exploited in the wild.” Cloudflare CEO Matthew Prince said the network saw thousands of attempts in the 10 hours before announcement, then “tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now.” InfoQ reported Cloudflare WAF rules at 03:02 UTC on October 21, about nine hours before release.
Jake Knott of WatchTowr said the exploits being sprayed indiscriminately “either don’t work at all, test for timing-based differences, or crash the target.” Sansec said public exploits do not work against a default PHP installation. Both issues are rated 9.2 under CVSS v4.0, with high attack complexity and additional attack requirements.
InfoQ, citing the PHP Foundation, said CVE identifiers began circulating two days early, a researcher mistakenly published a proof-of-concept video, and Chainguard unilaterally broke the embargo by publishing built images that contained the fix. The Foundation wrote that “any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.” The Dutch national cyber security centre took its website offline as a precaution, as did the Dutch House of Representatives.
Exposure Counts Depend on the Scanner
PHP is used by roughly 70% of websites, including WordPress, Drupal, Joomla, and Magento. SecurityWeek attributed the counts below to Censys, VulnCheck, and VirusTotal. Those populations are not the same.
| Source | Hosts reported | Patch or lifecycle signal |
|---|---|---|
| Censys (Oct. 21) | 2.58 million internet-facing hosts | Roughly 1.58 million reported a version; approximately 1.57 million were not patched |
| VulnCheck | More than 2.6 million hosts | Nearly all vulnerable; at least 1 million on end-of-life releases |
| VirusTotal | Roughly 5.1 million IP addresses | 1.1 million announced a version; approximately 272,000 supported and around 758,000 end of life |
Censys tracked nearly 3 million internet-facing hosts running PHP as of October 22. Commenters cited by InfoQ found PHP behind Nextcloud, OPNsense, OpenMediaVault, and Coolify.
CVE-2026-115560 and What to Change
Infosecurity Magazine reported that CVE-2026-115560 would not be patched until the next release. An application must set session.serialize_handler to php_binary or php_serialize, then switch it to php at runtime with ini_set() before session_start(), while session upload progress is still enabled. Applications that never change the handler at runtime can keep the feature on.
Set session.upload_progress.enabled=0 until the next regular bugfix release. For the patched pair, InfoQ quoted the project: “There are no complete mitigations; updating is the only safe choice.” Install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, the releases CISA urged. Sansec reports the bugs are present in every unpatched PHP since 5.4. On PHP-FPM, the session-lifecycle case was validated, but no complete exploit has been demonstrated for the out-of-memory bug on that SAPI.
- Check the full package version, not php -v. Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13 and still reports 8.3.6. Restart Apache and FPM workers after updating.
- Leave session.upload_progress.enabled=0 in place until the next bugfix release.
- Investigate from at least October 17, especially on Apache mod_php, where honeypots recorded remote code execution.
- Limit what a web-facing PHP process can launch or reach. SecurityWeek quoted ThreatLocker CTO Michael Jenkins: “Those controls are a backstop, not a substitute for patching, and should remain in place afterward.”
SecurityWeek quoted Sai Molige of Forescout, who said organizations should treat “How quickly can we identify where we run X?” as a measurable capability separate from patching speed. Hutchins said PHP2Shell is “like 50% the way towards Log4J,” with worse direct exploitation and a shorter tail than Log4j.
