Key facts
Each fact is linked to the source that supports it.- Confirmed: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fix CVE-2026-109618 and CVE-2026-109619. The upstream advisories describe pre-auth RCE paths in the PHP runtime. PHP Group GitHub / PHP Security Team GitHub / PHP Security Team
- Documented: exploitation attempts began before the patch, according to Amazon via SecurityWeek, and scaled sharply after disclosure according to Cloudflare. SecurityWeek Cloudflare
- Not established as of the 22 October 2026 (UTC) research cut-off: a confirmed mass compromise of production sites. The sources reviewed describe attempts, PoCs and laboratory exploitation, not a verified victim count. SecurityWeek Bitdefender
- Exposure estimates range from about 1.57 million unpatched hosts (Censys) to more than 2.6 million PHP hosts (VulnCheck). Different methods and populations mean the numbers cannot be combined. SecurityWeek
- Neither CVE appeared in the CISA KEV JSON catalog version 2026.10.21 when checked. That is a catalog observation, not proof that exploitation never happened. CISA
The evidence after one day
Less than two days after the coordinated release, the factual core is stable. PHP shipped fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The two advisories describe distinct memory-safety paths in the PHP runtime. The flaws are reachable before application code runs in the demonstrated mod_php case.
Everything beyond that needs a label.
Confirmed by primary sources
The affected branches, fixed releases, CVSS v4.0 scores, interim controls and the absence of a complete configuration workaround come from PHP and the GitHub security advisories. The CISA KEV JSON catalog version 2026.10.21 did not list either CVE when downloaded for this site.
Reported by vendors and media
Amazon observed an exploitation attempt on 17 October against a honeypot. Cloudflare tracked attack traffic before disclosure and a steep rise after it. WatchTowr, Hadrian, Patchstack, VulnCheck and others reported attempts with varying degrees of success. WatchTowr said the circulating PoCs it tested did not achieve RCE. Bitdefender said it had not observed exploitation and had not independently confirmed a reported AWS observation.
Not established
There is no publicly verified victim count. There is no confirmed mass compromise of production sites in the sources reviewed here. Exposure estimates are host counts produced by different scanners with different definitions; Censys, VulnCheck and VirusTotal numbers are not interchangeable and are not victim counts.
An attempt is not a compromise. A crash is not a compromise. A clean log is not proof of no compromise. These are different evidence states, and the site keeps them separate.
What administrators should do now
Patch the runtime, restart every worker, and verify what the serving process actually loads. If that cannot happen immediately, apply the official interim controls and reduce exposure; if those cannot be applied quickly, isolate the service. Then look for indicators of compromise with the understanding that the absence of alerts is not a clean result.
The verification guide and the mitigation guide are written for that sequence.
Sources for this page
- Full text read
- Full text read
- Full text read
- Full text read
- Full text read
- Full text read
- Full text read
- Metadata only
- Full text read
- Full text read
Revision history
| Time (UTC) | Recorded change |
|---|---|
| 22 October 2026, 16:45 UTC | Initial assessment, explicitly separating confirmed facts from vendor reports and unresolved claims. |
| 22 October 2026, 16:45 UTC | Current published version. |
This is an independent summary written by PHP2Shell Live. It is not a republished article and is not an official notice from PHP, any vendor or any agency. Read the editorial policy.