Topic starter
06/11/2026 6:35 pm
TL;DR: PHP2Shell exposure counts can differ by orders of magnitude because scanners count different objects, at different times, with different query logic, and banner-based version data can overstate patch status, according to Censys. Exposure reporting is only as reliable as the scanner, the unit of measurement, and the refresh cadence behind it.
Editorial analysis by NHI Mgmt Group, based on content published by Censys: “Censys takes census of the Internet like no one else”.
By the numbers:
- PHP announced an emergency release for two pre-auth remote code execution flaws in the PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2.
- Censys reaches a newly exposed host within hours, between 2 and 11 in its measurements, and revisits each service about every 8 to 14 hours.
- Censys adds roughly 20 new protocols and software fingerprints per week, with hundreds more in development.
Key questions
Q: How should teams count exposed services without double counting assets?
A: Count exposed services by unique service instance and listening endpoint, not by raw asset inventory, so one host with several ports or protocols is not counted repeatedly.
Q: Why do vulnerability exposure charts from different scanners disagree?
A: They disagree because scanners use different crawl depth, timing, fingerprint libraries, network paths, and confidence thresholds.
Q: How does banner-based version detection create false positives?
A: Banner-based version detection creates false positives when scanners trust the service greeting, HTTP header, or protocol banner as a version indicator.
Practitioner guidance
- Define the exposure unit before reporting risk Choose whether your reporting counts hosts, services, web properties, or application instances, and use that definition consistently across remediation, executive reporting, and validation.
- Separate version visibility from patch verification Require additional evidence before declaring a PHP instance fixed, especially when banners can be suppressed or version strings can reflect backported patches.
- Reconcile duplicate counts from shared hosting and multi-port services Deduplicate exposure results where one IP serves multiple sites or where the same software appears on several ports, so the same asset is not counted as several different findings.
Bottom line: The core problem is not only PHP2Shell itself, but the way inconsistent counting models can turn the same exposed surface into several incompatible risk pictures.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
PHP2Shell is an exposure-governance problem as much as a vulnerability event. When two public charts disagree by an order of magnitude, the issue is not simply bad data. It is that teams are comparing different measurement models and then treating the result as a single truth. For identity and access programmes, that same failure appears whenever inventory, ownership, and revocation decisions are based on incomplete or inconsistent telemetry. Practitioners need a counted asset model before they can trust remediation priorities.
A question worth separating out:
Q: What should teams do first after a mass-exploitation disclosure?
A: Teams should first confirm whether the disclosure matches their exposed services, then isolate the internet-facing paths, identify affected assets, and apply compensating controls such as firewall rules, virtual patching, or temporary shutdown where needed. They should also preserve scan evidence, trigger incident response, and prioritise vulnerable services with the highest exposure.
👉 Read our full editorial: PHP2Shell exposure counts show why internet scans disagree