We analyzed this claim: is it true that
internet security trackers report conflicting counts of vulnerable systems running PHP, ranging from two million to over one hundred million?

The wide differences in reported numbers reflect different definitions rather than factual disagreement. Automated scanners count public internet addresses, web addresses, or internal software packages, which cannot be treated as the same unit. Some scanners assume hidden systems are vulnerable, while others miss systems that have received quiet security updates. No study has produced an independently verified global tally of systems that attackers can actually break into.
Why the Internet Counts Flaws Differently
Wildly varying counts of exposed servers reflect different yardsticks, not a settled tally of vulnerable sites.
In a nutshell
When two critical security flaws hit the web programming language PHP in October 2026, cybersecurity researchers published wildly conflicting counts of exposed systems, ranging from two million servers to 167 million software packages. The numbers seemed to contradict each other, but they measured entirely different things: public web addresses, individual websites, corporate software packages, and incoming attack attempts. Outside scanners frequently misjudge safety because many systems hide their software versions or apply quiet vendor patches that external scans cannot detect. As a result, no single global figure shows how many systems can actually be hacked, and website owners must inspect their own servers to know if they are secure.
Highlights
- Security companies published widely divergent exposure estimates for PHP flaws, ranging from 2.61 million internet-facing hosts to 167 million installed software packages.
- Censys reported 4,184,559 hosts and 67,597,101 web properties on October 23, explicitly noting that hosts and web properties cannot be added together.
- Qualys reported 167 million PHP package installations across customer systems, with 581,000 installations receiving fixes in the first 24 hours.
- Onlayer estimated that 41.2% of monitored merchant websites across 20 markets ran an affected PHP version when the flaws became public.
From the Editor’s Diary
A soaring global count of vulnerable servers measures how much software exists, not how many websites can actually be broken into. Real security depends on verifying the code running inside your own system rather than watching an internet-wide dashboard.
Who's involved
PHP security team
Volunteer developers maintaining PHP, the programming language powering millions of websites
goal → Ship emergency software updates and explain which setups require repair
Censys
Internet security firm that runs global automated scans of internet servers
goal → Map reachable web servers, follow patch adoption, and refine scanner accuracy
VirusTotal
Google-owned cybersecurity platform analyzing internet addresses and software traits
goal → Map internet-facing software, uncover masked servers, and help defenders focus on risks
VulnCheck
Cybersecurity intelligence firm monitoring internet-facing systems and live cyberattacks
goal → Identify exploitable software setups and separate verified weaknesses from estimates
Qualys Threat Research Unit
Vulnerability research team inside cloud security provider Qualys
goal → Track installed software across corporate customer servers to guide emergency patching
Palo Alto Networks Unit 42 and Cortex Xpanse
Threat research and internet monitoring teams within cybersecurity firm Palo Alto Networks
goal → Detect exposed digital infrastructure and help organizations prioritize repairs
Website operators and hosting providers
Engineers and technology companies operating web applications and hosting infrastructure
goal → Install updates, maintain live services, and verify that their web systems are protected
Operating-system and PHP distribution vendors
Software distributors such as Canonical, Debian, and Plesk that package and ship PHP
goal → Provide vendor-specific security patches, including fixes backported to older software releases
In short
Global counts of vulnerable web systems do not measure the same thing, leaving site operators unsure whether millions or hundreds of millions of servers remain exposed. PHP is the foundational programming language that translates code into viewable pages for millions of online shops and corporate websites. When two severe flaws named PHP2Shell emerged, security firms published vastly different estimates of the danger. These headline numbers do not prove how many websites are truly open to break-ins.
The most likely outcome is that website operators will have to check their own servers directly rather than trusting public internet trackers.
That outcome is near-certain because automated scans cannot see how a server is built inside or whether it has received quiet security fixes.
How it unfolded
An Early Security Leak Starts a Counting Race
On October 20, 2026, word of two severe vulnerabilities in PHP leaked online ahead of a coordinated disclosure schedule. The PHP security team quickly posted an advisory warning that official repairs would arrive on October 21 at 14:00 UTC. Ubuntu later confirmed that the original coordinated plan had targeted October 22. Because investigators could not verify who first leaked the details, the PHP team's public notice stood as the earliest official alert. Cybersecurity companies immediately began scanning the web to measure the attack surface. An early observation by scanning firm Modat ended before fixes were ready, while VirusTotal, VulnCheck, Black Kite, and Censys published initial measurements on October 21. Their wildly differing counts revealed how hard it is to take an internet census.
The First Scans Produce Different Internets
When the PHP security team published fixed versions on October 21, analysts gained a concrete benchmark to judge against their scan logs. Even with that baseline, agreement on the code did not yield agreement on the number of victims. VirusTotal surveyed internet protocol addresses, known as IP addresses, the unique numbers assigned to every device on the internet. VulnCheck counted reachable physical servers over a 30-day window. Black Kite combed through database search results, correcting search errors that accidentally bundled unrelated releases together. Censys combined individual machines with public web addresses. Each firm measured a different unit, creating mismatched tallies from the very first afternoon.
Machines Become Instances and Web Traffic Spikes
By the second day, public estimates grew more divergent as research firms shifted how they defined exposure. Palo Alto Networks estimated over 22.6 million exposed cloud instances, while Censys increased its server and website tallies after improving its scanning tools. These jumps did not mean millions of brand-new vulnerable machines had suddenly appeared on the internet. Security firm Check Point noted that 10% of monitored organizations saw attack traffic, though it clarified that probe attempts do not equal successful break-ins. Meanwhile, cybersecurity company Netcraft sent out 50,000 warning notices to website owners. In the public eye, two critical flaws beneath millions of websites had turned into several separate debates over what was actually being counted.
Counts Swell into the Tens of Millions
On October 23, the reported figures multiplied into the hundreds of millions as companies looked inside private corporate networks. Censys mapped more than 67 million public web addresses, but only 4.18 million physical servers. Qualys looked inside customer enterprise networks and counted 167 million PHP software installations, while e-commerce analytics firm Onlayer estimated that 41.2% of merchant sites were exposed. These massive tallies did not contradict one another mathematically because they measured fundamentally different universes. Qualys examined software packages installed deep inside private enterprise systems, while Censys scanned visible public doors and Onlayer tracked online retail shops.
Security Experts Demand Internal Proof
By October 24, cybersecurity specialists began warning that looking at a website from the outside cannot tell you if it is safe. Qualys clarified that simply spotting a PHP server does not prove that it can be hacked. Trend Micro pointed out that when a website returns an old version number, that number may hide an operating-system backport—a practice where Linux distributors insert a security fix into older software without changing its public version label. Conversely, a server that hides its software label completely could still run obsolete code. True protection requires auditing the actual software running on the server, not scanning website labels.
Where things stand
As of October 25, 2026, security analysts agree on the cause of the conflicting numbers, but no validated global census of truly vulnerable servers exists. Recent reports largely repeat earlier vendor tallies. Censys maintains an active dashboard showing about 34.28 million services reporting affected versions, 7.13 million updated services, and 49.70 million services that conceal their version details. The dashboard records 288.66 million responses over 24 hours, but those figures represent automated pings, not distinct servers. Its dashboard also lists certain older PHP versions as vulnerable even though official vulnerability notices place those releases outside the affected range.
The boundaries between the metrics are now understood. Counting internet addresses shows how widely PHP is used, but cannot confirm if the code is open to attacks. Counting web domains tallies online properties, not individual computers. Counting customer packages reveals corporate software inventories rather than public web servers. Counting firewall blocks tracks incoming attack noise, not successful compromises. Until software vendors and scanners agree on a single way to identify active server programs, headline numbers will measure how widely software is deployed rather than how many websites can actually be broken into.
PHP2Shell: the PHP security crisis

PHP emergency website patch faces unproven bypass fears
21 October 2026Online warnings claimed that a new fix for the programming language powering millions of websites had failed, but technical evidence shows no broken security update.
PHP fixes flaws rated 9.2 as exploit leaks drive early attacks
21 October 2026Millions of web servers face takeover risks after flaws leaked before fixes arrived.