PHP2Shell exposure counts show why internet scans disagree

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Censys's research: PHP2Shell exposure counts varied because different scanners measured different objects, different timestamps, and different version signals.

Why it matters: For IAM and security teams, the lesson is that exposure data is only actionable when the collection method, object model, and refresh cadence are understood well enough to support patch prioritisation and verification.

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.

Context

Exposure data becomes misleading when teams treat every count as the same thing. One service, one IP, one web property, and one scan response can each tell a different story about the same environment, especially when shared hosting, multiple ports, and version banners are involved.

The PHP2Shell case shows that the real governance problem is not just whether a vulnerability exists, but whether the measurement model can distinguish affected services from duplicated observations, hidden versions, and stale scan results. Data flow mapping helps frame that distinction when teams need to understand what is actually being counted.

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. Use deduplication keys such as IP, port, protocol, hostname, and application context, then reconcile container, virtual machine, and load balancer views to avoid double counting the same exposed service.

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. One tool may identify a banner or certificate field as evidence of a service, while another requires an active response or authenticated check, so exposure charts often differ until results are normalised and deduplicated.

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. Those strings can be stale, generic, proxied, or intentionally spoofed, so the identified product or release may be wrong. Validation should combine banner data with active probing, configuration checks, and authenticated inventory where possible.

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.

Technical breakdown

Why exposure counts diverge across scanners

Exposure charts drift because they inherit the scanner’s coverage, refresh rhythm, and matching rules. If one dataset is built from first-party scans and another from licensed or resold data, the counts will not align even when both are looking at the same target population. The unit of measurement also matters: counting IPs, services, websites, and scan responses produces different answers. For PHP, shared hosting and multiple listening ports make those differences especially visible. A headline count is therefore an aggregation choice, not a neutral fact.

Practical implication: Standardise what your programme counts before using exposure numbers for prioritisation or reporting.

How banner data and version strings inflate PHP exposure

Banner-based detection is useful, but it is not the same as verified patch state. PHP often reveals its version through the X-Powered-By header, and that signal disappears when expose_php is disabled. Even when a version is visible, distributions can backport fixes into older version numbers, so the string may overstate risk. Text-matching queries can also double count related versions when a prefix search matches multiple minor releases. The result is a conservative upper bound, not a precise exposure total. See the Data Security Guide.

Practical implication: Treat version banners as indicators to verify, not as proof that a host is still vulnerable.

Why refresh cadence changes patch visibility

An exposed service only becomes visibly fixed after the scanner revisits it and records the change. That means the same environment can look vulnerable longer or shorter depending on revisit frequency, coverage depth, and whether the scanner reaches the right port or path. Censys also shows that deeper fingerprints, historical records, and service-level views can materially change what appears to be exposed. In other words, visibility is not static, and exposure intelligence should be read as a time-series signal rather than a single snapshot.

Practical implication: Use recurring scans and history to confirm whether remediation has actually reduced exposure.

Threat narrative

Attacker objective: Exploit internet-facing PHP services before patch adoption and visibility converge, then use remote code execution to gain control of affected hosts.

1. Entry began with the emergency disclosure of two pre-auth RCE flaws in the PHP core, which created an immediate exploit target across exposed PHP services.
2. Credential or version discovery then hinged on banner data, public exploit demonstrations, and patched binaries that let observers study the fix before full coordination finished.
3. Impact would come from remote code execution on internet-facing PHP instances, especially where shared hosting and multiple exposed ports widened the reachable surface.

Breaches seen in the wild

• PHP Git server compromise 2021: Commits faked in two PHP maintainers' names put a backdoor in php-src; the pushes used php.net passwords, likely from a leaked user database.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Banner-derived vulnerability counts create a false sense of precision. A visible version string is only one signal, and even that signal can mislead when fixes are backported or when PHP hides its own version output. That makes exposure reporting a problem of evidence quality, not just scanner breadth. Data security guidance is relevant here because the same discipline that governs sensitive-data discovery also applies to externally visible service discovery and classification. Teams should align reporting to verified state, not to the loudest banner.

Shared-hosting environments amplify measurement error. One IP can host thousands of sites, and one host can answer on several ports, so a single counting method will miss some objects and duplicate others. This is a governance issue because patch ownership, remediation SLAs, and board reporting all depend on the object model used for counting. When exposure is aggregated incorrectly, accountability becomes blurry and fix validation becomes unreliable. Practitioners should define the unit of exposure before they define the remediation target.

History matters because exposure is a moving target, not a static list. Censys’s time-series view shows that remediation visibility lags behind patching, and that lag affects how teams interpret risk and closure. That matters for both vulnerability management and access governance, where stale telemetry can keep a resolved issue alive in reporting long after the change landed. The operational lesson is straightforward: use repeatable scans and historical evidence to separate real exposure from delayed visibility.

PHP2Shell highlights the need for countable, attributable internet exposure. A programme cannot govern what it cannot consistently enumerate, especially when the same service can be represented as an IP, a web property, or a software record. That principle applies directly to machine identity and service exposure, where the inventory itself becomes a control surface. Teams should treat exposure measurement as a governed data product, not a one-off report.

What this signals

Exposure intelligence needs an ownership model, not just a bigger scan. The more important control is not whether a platform can see more hosts, but whether it can map each finding to a governed asset and a repeatable remediation state. Without that link, reporting becomes numerically impressive but operationally weak.

Countable internet exposure is now a governance requirement. Teams that rely on inconsistent service counts will struggle to justify patch prioritisation, validate closure, or explain residual risk. The practical response is to treat exposure inventory as part of control evidence, not as a side effect of scanning.

For practitioners

• 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.
• Use history to prove remediation closure Compare repeated scan results over time so you can distinguish a true patch from a delayed observation and avoid leaving closed exposures in reporting.

Key takeaways

• 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.
• Banner strings, shared hosting, multi-port services, and scan timing all affect whether a PHP service appears vulnerable, fixed, or counted twice.
• Teams need a defined exposure unit, repeatable scans, and verification evidence before they can trust remediation reports or board-level metrics.

Related NHI Mgmt Group resources: Data flow mapping for security and privacy · Data Security Guide · Log Source Coverage Matrix Template · Threat vs Vulnerability vs Risk Guide

Key terms

• Unknown Exposure Count: Unknown exposure count means the number of records affected by a breach has not been confirmed or publicly reported. This creates a material visibility problem, because organisations, consumers, and regulators cannot fully judge scope, notification impact, or downstream risk without reliable record totals.
• Banner-Based Detection: Banner-based detection is a method of identifying software or services from the text they present during connection setup, such as protocol headers, greetings, or error messages. Security tools use banners to infer product type and version, but the method can be unreliable if banners are hidden, altered, or generic.
• Shared Hosting: Shared hosting is a web hosting model where multiple customers place their sites on the same physical server and share its compute, memory, storage, and network resources. In identity and security terms, tenant isolation is limited, so misconfiguration, weak access controls, or one compromised account can affect neighboring workloads.
• Scan Revisit Cadence: Scan revisit cadence is the planned interval for running a new security scan against the same assets or services. It sets how often exposure or vulnerability findings are refreshed, so teams can track whether a service is still present, whether evidence has changed, and whether remediation has taken effect.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when your programme needs a shared baseline for identity, secrets, and workload governance.