Summary
Researchers confirmed a PHP2Shell remote-code-execution chain against an intentionally favorable, unpatched single-worker mod_php honeypot after PHP released fixes on October 21. OX Security counted 127,430 fixed hosts among 1,990,772 measurable hosts in affected version ranges on October 26, reporting 93.6% still unpatched. These are important signals, but the exploit result is not a measure of reliability across PHP deployments, and the scan is not a census of vulnerable or compromised systems.
What happened
The reported chain ran against Apache mod_php with unpatched PHP 8.4.26. An approximately 800 KiB decoded cookie dump yielded a function address that appeared in a later execution payload. That supports the claim that the flaws can produce remote code execution in this setup, but the report says the demonstration used an intentionally favorable single-worker profile. It does not establish reliability across other worker counts, PHP builds, or configurations.
OX Security’s October 26 Shodan-based scan identified 1,990,772 hosts in affected version ranges, of which 127,430 were on fixed releases and 1,863,342 were not. The firm also estimated about 1.33 million affected hosts ran end-of-life PHP 8.1 or older. Its measurements rely on publicly advertised versions and exclude hosts whose versions are concealed. Separately, CISA added the flaws to its Known Exploited Vulnerabilities catalog. That status raises remediation priority for covered federal agencies, but does not establish the number of real-world compromises.
What the archive adds
The archive’s prior PHP2Shell coverage records the emergency fixes and the early gap between release and adoption. According to OX Security’s reported measurements, fixed-version hosts rose from 245 on October 21 to 127,430 on October 26, while most measurable affected hosts remained unpatched. The dossier also notes two constraints that complicate a single headline percentage: unsupported PHP 5.4–8.1 lacks upstream fixes, and exploitability may differ by deployment mode. It cites assessments that mod_php is higher risk while PHP-FPM on RHEL 8+ makes reliable RCE difficult. These distinctions do not negate exposure; they show why exposed-version counts are not equivalent to exploitable or compromised-host counts.
Trend signal
The concrete pattern is uneven remediation across a fragmented installed base, not a single universal exploit curve. PHP’s fixes were available within days of disclosure, but the OX scan indicates that many publicly versioned hosts had not moved to fixed releases five days later; end-of-life deployments cannot take the ordinary upstream patch path. At the same time, deployment-specific exploitability matters: a working chain against one mod_php profile cannot be generalized to every PHP-serving stack. The figures therefore describe different things—patch adoption, visible version ranges, and proof of exploitation—and should not be collapsed into one estimate of incident scale.
Why now
The primary evidence shows PHP shipped fixes on October 21 and a working chain was confirmed within days, so defenders faced a short interval between remediation availability and demonstrated exploitation. According to JFrog Security Research (d3), the emergency release had been announced in advance while researchers were already probing the flaws, compressing the response window. The affected population spans multiple PHP request-serving deployment types, but the reported proof is limited to one favorable mod_php configuration. The dossier also identifies unsupported PHP 5.4–8.1 as a structural remediation constraint because upstream fixes are unavailable for those versions.
Connections to other events
The numbers are useful as a measure of response friction, not a direct count of targets attackers can reliably compromise. OX Security found 1,863,342 measurable hosts still on affected versions, but its scan cannot count hosts hiding their version and cannot establish successful exploitation. The honeypot proves the chain worked in one deliberately favorable mod_php configuration, not across the whole scanned population. The dossier also cautions that a Unit 42 telemetry pool of 22.6 million is potentially exposed infrastructure, not a count of vulnerable or compromised hosts. Read together, these measurements justify urgent inventory and triage—but not a claim of millions of exploitable victims.
Why it matters
Operators should treat public PHP version counts as a starting queue for verification. First identify which systems are internet-facing, what PHP version and deployment mode they use, and whether that version has an upstream fix. Unsupported PHP 5.4–8.1 requires a different decision from a supported release: migration, isolation, or another compensating measure may be necessary rather than a routine update. For buyers, a provider’s exposure and remediation evidence is more informative than an aggregate internet scan. For incident responders, the confirmed exploit warrants checking exposed systems, while avoiding the assumption that every deployment is equally susceptible.
What happens next
- Publicly measurable fixed-version PHP hosts will increase, but version-based scans will continue to show a substantial affected population because unsupported systems cannot take a standard upstream update. (3 months, 70%). Watch for: A follow-up scan using disclosed comparable methodology reports more fixed hosts and continues to identify affected end-of-life versions.
- Exploitability reporting will remain deployment-specific rather than establishing one reliable PHP2Shell chain across all affected configurations. (6 months, 65%). Watch for: Technical advisories or incident reports distinguish outcomes by PHP deployment mode or configuration rather than reporting uniform success.
- Public exposure estimates will be cited alongside stronger caveats about telemetry pools and version visibility, rather than as counts of compromised systems. (12 months, 60%). Watch for: A subsequent security report explicitly separates potentially exposed assets, measurable affected versions, confirmed exploitation, and confirmed compromises.
Limits and uncertainty
The exploit demonstration was on an intentionally favorable single-worker mod_php honeypot; the source does not establish reliability across builds, worker counts, or applications, nor the number of compromised systems. OX Security’s figures cover hosts with publicly measurable versions and do not establish total exposure or patch rates among concealed hosts. The dossier’s deployment-mode assessments and Unit 42 telemetry figure are contextual constraints, not direct measurements of this incident’s victims. This take would need revision if reproducible exploitation across other configurations or credible incident counts emerged.
Skill to build now
Practise exposure measurement with uncertainty attached: inventory one set of public PHP services, verify version and deployment mode, classify support status, and record which entries are unknown because their versions are hidden. First exercise: compare that verified list with a public-version scan and write down which conclusions the scan can and cannot support.
Reader takeaway
This week, build a verified PHP exposure list rather than treating the Shodan percentage as your own risk score. For each public service, record version, deployment mode, support status, and patch or isolation plan; separately flag systems whose versions cannot be verified. Prioritize exposed affected systems, but assess exploitability and compromise locally instead of inferring either from a public version banner.
Open question
Will the confirmed chain remain chiefly a risk for favorable mod_php setups, or will reliable exploitation across other deployment modes turn today’s patch-adoption counts into a broader compromise signal?