What happened
Bitsight published an analysis of scanning, exploitation discussion, and patching after the PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The company says the flaws arrived with predictions of Log4Shell-scale mass exploitation because PHP has a large internet footprint and the reported vulnerable ranges covered branches from PHP 5.4 through 8.5. Its conclusion is more qualified: the vulnerabilities are serious and are being scanned for, but reliable mass remote-code execution had not yet emerged in the evidence it examined.
The company observed roughly 30 million PHP hosts before the disclosure, including 18.4 million advertising a vulnerable version. In a more bounded patching view, its scan data covers 9.47 million hosts that ran a vulnerable PHP version before the October 21 fixes. Of those, 33.5% were running a patched build by the time of the report, published October 29. Bitsight characterizes that as more than a third of systems patched within the first seven days.
The aggregate conceals a large difference between maintainable and obsolete systems. On supported PHP branches, 8.2 through 8.5, Bitsight counted 4.13 million hosts and says 68.6% patched within a week, reaching 85% by October 27. In contrast, only 6.4% of 5.34 million end-of-life hosts running PHP 8.1 or older had patched. PHP 7.4 is the starkest example: 91% of the 1.73 million observed hosts stayed on that version. The figures measure publicly observable version advertising and patch adoption, not confirmed compromise.
Patching also varied by geography and sector in the supplied data. The United States was at 26.2% patched; China, South Korea, and Taiwan were each below 6%. Finance trailed at 26.3%. These are observations of the exposed population Bitsight could see, not a census of every PHP deployment or a measure of any organization’s internal environment.
Bitsight also examined hostile activity. Amazon had reported scan activity dating to October 17, before the public disclosure leak on October 20. Bitsight identified 1,035 PHP-fetching addresses across 25 clusters. It says some traffic came from suspicious infrastructure and botnet operators appeared to be experimenting, but that much of the observed traffic lacked the structure needed for exploitation. One source sent requests combining oversized bodies, upload-progress requests, and deeply nested fields; another had attempted other malware delivery activity. The report argues that raw request volume overstated demonstrated exploitation capability.
Its review of underground discussion reached a similar conclusion. Participants were looking for reliable working exploits, while many public proofs of concept reportedly worked in laboratory conditions but failed against live targets because of build-specific offsets and ASLR. Bitsight found no verified claim of mass compromise. That does not make the flaws safe: it says serious vulnerabilities “can and will be exploited,” but that target-specific conditions and early patching bought defenders time.
What the archive adds
This is a new measurement on a known story. Earlier coverage recorded CISA’s immediate patching guidance and an OX Security day-five estimate that 93.6% of measurable instances remained exposed. Bitsight’s later view reports a higher overall patch rate and explains why supported and end-of-life branches should not be treated as one population.
Trend signal
This supports the archive assumption that PHP2Shell exploitation will keep growing while unpatched internet-facing PHP hosts remain. The important refinement is that the available target pool is not static: supported branches can move rapidly, while end-of-life branches create a much more persistent reservoir of unpatched systems.
Why now
The report follows the October 21 fixes and measures the first week of remediation, when defenders were reacting to warnings and attackers were still searching for dependable exploitation paths. That timing makes the supported-versus-end-of-life split more informative than a single global percentage.
Connections to other events
The finding connects directly to the earlier CISA patching alert and to OX Security’s day-five exposure measurement. The earlier work established urgency and a large residual exposed population; Bitsight adds a different scan-based observation after a week and separates systems that can be updated through supported release lines from those whose owners face a migration problem.
Why it matters
AI builders often focus security attention on prompts, model access, connectors, and agent permissions. Those controls matter, but the services hosting applications, retrieval systems, workflow tools, and internal APIs remain ordinary software stacks with ordinary patch dependencies. A vulnerable runtime on an internet-facing service can undermine the surrounding AI security design.
The practical distinction here is not merely whether a team applied one emergency update. It is whether every production service is on a supported runtime that can receive the next one. Bitsight’s figures suggest that teams operating maintained branches can respond quickly, while organizations with legacy PHP face a materially different task: inventory, compatibility testing, migration, and retirement. Treating both groups as equally “unpatched” hides the engineering and risk-management work required.
What happens next
- Supported-branch patch adoption will continue to rise faster than end-of-life remediation (3 months, 75%). Watch for: follow-up internet scans separating PHP 8.2–8.5 from PHP 8.1 and older.
- Attackers will keep probing PHP2Shell while reliable exploit chains remain valuable (3 months, 70%). Watch for: verified incident reports or a reproducible exploit that works across common production configurations.
Limits and uncertainty
Bitsight’s results are internet observations, not direct telemetry from every affected server. A version visible to a scanner may not describe every component of a deployment, and a patched advertised version does not prove that a host is securely configured or uncompromised. Conversely, the data does not establish that every host remaining on an older version is reachable through a vulnerable PHP configuration. The report’s discussion of attacker behavior is evidence of scanning and forum activity, not proof that exploitation is absent. Its regional and sector figures should therefore be read as comparative measurements of the observed population, not definitive national or industry exposure totals.
Skill to build now
Create a runtime-support inventory for every internet-facing service that backs an AI application: PHP version, owner, deployment location, public exposure, and last successful patch date. Separate services that can take a vendor-supported update from those requiring a migration. Then test the patch path in a staging environment and assign an explicit retirement date to every unsupported branch. This converts a broad vulnerability alert into a tractable queue of owned remediation work.
Reader takeaway
PHP2Shell did not produce verified mass compromise in Bitsight’s view, but that is not the same as closure. The first week’s patching data shows a split: maintained systems can move, while end-of-life systems largely remain. For builders, supportability of the underlying runtime is a security capability, not maintenance housekeeping.
Open question
Will public exploitation become reliable enough to turn the large end-of-life PHP population into a sustained campaign, or will patching and configuration diversity continue to constrain attackers?