OX Security tracked over 2.2 million publicly exposed PHP instances following disclosure. Within 24 hours, only 14,151 affected systems visible on Shodan had been patched. The rate at which critical vulnerabilities are discovered continues to outpace our ability to remediate them at scale
Overview
On October 21, PHP released emergency fixes for PHP2Shell, two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — that allow unauthenticated remote code execution in the PHP engine itself.
Governments and security agencies around the world urged organizations to patch immediately. Some took systems offline. But 24 hours later, our data shows just how slowly that remediation is actually happening.
OX Security tracked more than 2.2 million publicly visible PHP instances through Shodan over the 24 hours following disclosure. Of the 1,974,890 measurable instances running versions in the affected range after 24 hours, just 14,151 were showing one of the newly patched PHP versions.
That’s 0.7% patched.
Put another way, 99.3% were still not showing a patched PHP version 24 hours after emergency fixes became available.
And while patching accelerated over the course of the day, it barely dented the affected population. At our initial measurement, only 245 instances were showing a patched version. Twelve hours later, that number had risen to 4,519. After 24 hours, it reached 14,151.
We also broke the data down across popular PHP-based technologies including WordPress, phpMyAdmin, Drupal and Laravel. The pattern was consistent: Roughly 99% of the affected hosts we could measure were still not showing a patched PHP version.
The findings illustrate the challenge facing defenders as critical vulnerabilities and attacks happen faster than many organizations can remediate them. Even after an emergency patch, worldwide warnings and extraordinary attention, the overwhelming majority of the affected systems we could measure remained unpatched 24 hours later.
Methodology and limitations: OX Security queried Shodan over the 24 hours following disclosure. PHP versions were identified from version information exposed publicly by indexed hosts, including headers such as X-Powered-By. Hosts that do not expose their PHP version cannot be classified using this methodology and are not included in our affected-versus-patched calculations. Because Shodan is a continuously changing index, changes in the total number of indexed hosts should not on their own be interpreted as evidence that systems were patched, isolated or taken offline.
For a flaw of this severity, standard emergency playbooks dictate a ‘drop-everything’ response where patching and validation should take no more than an hour. Yet 24 hours later, 99.3% of affected systems remain unpatched. This gap highlights a dangerous disconnect: while deployment itself takes minutes, operational fear of breaking live production systems, complex dependencies, and delayed approvals still outweigh immediate security threats in the real world.
How Many PHP Instances Were Secured?
At our initial assessment, Shodan showed 2,224,364 publicly visible PHP instances. Of the instances whose versions we could classify, 1,991,515 were running versions in the affected range, while just 245 were showing one of the newly patched releases.
Around 233K instances contained an earlier version not vulnerable to PHP2Shell (PHP 5.3 and older).
Twelve hours later, we identified 4,519 patched instances.
After 24 hours, that number had risen to 14,151 — just 0.72% of the measurable affected population.
| Timeline | Identified PHP Instances | Unpatched Instances | Patched Instances | Percentage Unpatched |
| First Assessment | 2,224,364 | 1,991,515 | 245 | 99.99% |
| 12 Hours | 2,194,607 | 1,965,127 | 4,519 | 99.77% |
| 24 Hours | 2,206,457 | 1,974,890 | 14,151 | 99.28% |
What About PHP-Based Websites?
The same pattern appears across widely used PHP-based technologies, including WordPress, phpMyAdmin, Drupal, Laravel, Joomla, cPanel and Magento.
Among the affected hosts whose PHP versions we could identify through Shodan, roughly 99% were still not showing a patched PHP version after 24 hours.
The data covers only publicly indexed hosts that expose enough PHP version information for us to classify them, so it should not be read as an estimate of the total vulnerable population for any individual technology.
| Technology | Hosts found (PHP version visible) | Affected | Patched | % Affected |
| WordPress | 41,882 | 33,075 | 299 | 99.1% |
| phpMyAdmin | 33,927 | 28,285 | 157 | 99.45% |
| Drupal | 5,078 | 3,919 | 31 | 99.22% |
| Laravel | 2,261 | 2,040 | 36 | 98.27% |
| Joomla | 1,099 | 646 | 4 | 99.38% |
| cPanel | 2,403 | 587 | 0 | 100.0% |
| Magento | 126 | 48 | 0 | 100.0% |
Conclusions
PHP2Shell triggered emergency patches, government warnings, and worldwide attention. Yet 24 hours later, 99.3% of the affected PHP instances we could measure were still not showing a patched version.
That gap matters beyond PHP.
Security teams are already dealing with a constant stream of critical vulnerabilities, active exploitation and software supply chain attacks. PHP2Shell arrived as organizations were also responding to incidents such as the LiteLLM compromise. When multiple emergency-grade issues arrive at once, the challenge is no longer simply knowing that something is critical. It is knowing what is exposed, what can actually be exploited, what matters most and what needs to be fixed first.
AI makes that problem harder. It is accelerating vulnerability research and making it easier to find and develop exploits for flaws buried in mature software. But organizations still have to identify affected systems, determine exposure, test updates, prioritize remediation and deploy fixes across real production environments.
We are getting faster at finding critical vulnerabilities than we are at removing them from the internet.
PHP2Shell may be an early indication of what that imbalance looks like at scale. If AI continues to accelerate vulnerability discovery, defenders will need to get better not only at patching quickly, but at understanding their attack surface, reducing unnecessary internet exposure and functionality, monitoring for exploitation, and prioritizing the vulnerabilities that create the greatest actual risk.
Finding vulnerabilities faster is only an advantage if defenders can fix them fast enough to keep up.
