- AhnLab's ASEC explained that its "110,000 Korean PHP servers" figure counts search results for PHP-identified hosts from one tool. It does not count websites or vulnerable servers.
- Three search services returned 47,209, 125,859 and 2,848,656 for South Korea, because each counts a different unit. ASEC says the figures should not be compared.
- Before acting on any exposure number, ask what one item in it means. Then rely on your own inventory of PHP systems and their update status.
A number in a security headline does a lot of work. It sets urgency, shapes budgets and gets repeated in board packs. Few readers ask what the number counts. AhnLab's security research team ASEC has just shown why that question matters.
The lesson here: a statistic is only as useful as its unit. Before you act on a count, ask what one item in it is.
The figure that drew questions
On October 21, AhnLab published an article about two PHP vulnerabilities. It cited roughly 110,000 Korean PHP server IP addresses. Readers asked where that figure came from. The next day ASEC published a methodology note.
ASEC states plainly that the figure does not come from counting Korean websites one by one. It tallies the hits that a single internet asset search engine tagged as PHP. Such engines map the servers and services reachable online. ASEC adds that the figure does not show how many web servers are exposed to the vulnerabilities.
Three tools, three very different answers
ASEC queried three private search services, based in the US, South Korea and China. It calls them Company A, B and C. The 110,000 figure came from Company A, whose query asks for hosts where the software product is "php".
On October 21, Company A returned 112,183 results for South Korea. On October 22, it returned 125,859. ASEC notes that results shift with the time of the survey.
Company B returned 47,209 instances for South Korea, ranking it fourth. Its worldwide total was 852,802, about 28% of Company A's total. Company C returned 2,848,656 entries for South Korea, ranking it 13th.
ASEC does not read these gaps as differences in how many PHP servers exist. It reads them as differences in survey scope and in what each service counts as one result.
How a count can multiply itself
Here is the mechanism. Some services count one IP address as one result. Others count each pairing of an IP address and a port. Others count each domain name. ASEC compares this to counting an apartment building as one building or as 100 households.
PHP makes the gap wider. ASEC notes it is widely used in shared hosting, where many websites sit on one web server. One server can then appear as many results, one per domain. ASEC says results can differ by several times between services even under similar search conditions.
Company A's results are based on hosts, meaning IP addresses. That is why ASEC says the accurate description is "results of queries for PHP-identified hosts in Korea", not the number of domestic websites.
Two limits on what the number can tell you
First, the search did not check PHP versions or vulnerability status. So the count cannot show how many servers are affected by either flaw.
Second, "Korea" here means geographic location. The services classify results using their own region-level location data. The count does not cover all sites run by Korean companies and organisations, and it may include hosts that are not theirs.
ASEC adds that the services differ in scope and timing, so figures from different services should not be compared or added together.
What still holds
ASEC argues that scale matters more than the exact number. Company A returned about 3 million PHP-related results worldwide. Company C returned about 19 million. In Korea alone, Company A identified 125,859 instances.
On the flaws themselves, ASEC says they affect virtually all PHP versions, including the supported 8.2 through 8.5 and older unsupported ones. Servers without security updates could be targeted, in Korea or elsewhere. This note does not name CVE identifiers for the two flaws. Check the original AhnLab article or your vendor advisories for them.
Questions to put to your team
Ask what unit any exposure figure uses: IP addresses, ports, domains or businesses. A number from one tool should not be set against a number from another.
Ask for your own inventory, not a national estimate. Which of your systems run PHP, which version, and who owns the update? Shared hosting providers are worth a direct question: have they applied the PHP security updates AhnLab advises?
Ask vendors and analysts to state what their headline number leaves out. AhnLab did so after the fact, which is to its credit. It is better when the caveat comes with the number.
A large count can start the conversation. Only your own inventory can end it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AhnLab ASEC.
