Summary
- Infrawatch estimated patch coverage at approximately 25% of visible UK PHP hosts at midday on 26 October.
- The corresponding Netherlands estimate was approximately 50%; Germany, Austria and Switzerland were near 40%.
- The figures are a dated external-host sample and do not establish compromise rates or today’s patch coverage.
An Infrawatch measurement of publicly visible PHP hosts at midday on 26 October suggested that patch deployment in the UK lagged several European countries following the PHP2Shell disclosures. Roughly a quarter of the UK hosts visible to its scanning system appeared patched, compared with approximately half in the Netherlands. Those figures concern detectable hosts, not all British organisations.
Computer Weekly’s report, published on the evening of 26 October, also put Austria, Germany and Switzerland closer to 40% patched, with Belgium, Bulgaria, Czechia and Finland at around 30%. Globally, the study counted 412,000 publicly accessible PHP hosts as patched by midday on 26 October, or about 19% of the visible total in that dataset.
These percentages are measurements from one provider at a particular time. They are not audited shares of all organisations running PHP in each country, and they should not be projected onto invisible internal systems or every application with a PHP dependency. A different scanning project may define a vulnerable host, patch signal or denominator differently and obtain substantially different national rates.
Patch availability is not patch deployment
PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, involving memory and request-state handling. Under specified conditions, an unauthenticated attacker could cause remote code execution. Supported security updates have been released, but an available patch does not guarantee every exposed server has received it.
For large organisations, PHP may be present in several forms: public websites, applications maintained by outsourced developers, internal portals, bundled software and appliance management interfaces. A central software inventory can miss instances installed by a third-party product or hosted outside normal infrastructure-management processes. The resulting delay may reflect asset discovery and change-control constraints, not simply a decision to ignore the warning.
Some services also depend on frameworks or modules with their own compatibility requirements. Administrators may need to coordinate an application update, infrastructure replacement or vendor hotfix before they can move a production service to a fixed runtime. Those constraints require testing, but they do not remove the risk while a vulnerable system stays reachable.
The UK’s National Cyber Security Centre has called for organisations to identify all installations running PHP, starting with internet-facing deployments, and apply supported versions or temporary mitigations where appropriate. Its advisory states that older unsupported versions are also a concern and should not be treated as outside scope merely because no routine upgrade path remains.
What national comparisons show
The relative country rates provide an indication of uneven remediation progress, but the numbers may reflect different hosting mixes, detection coverage and update practices. A country with more managed platforms may show faster visible change than one with a larger estate of bespoke or legacy installations. Infrawatch’s published snapshot alone does not establish those causes.
There is also a distinction between a patch rate and exploit exposure. A vulnerable host might sit behind additional controls, while another could be internet-accessible and directly reachable through a dangerous request path. The source data can help identify broad trends but cannot confirm whether any individual website has been compromised.
The PHP vulnerabilities have already prompted British government warnings, published exploit research and vendor-specific responses. This measurement is a separate development: it attempts to show how quickly identified systems are being secured after the patches became available. Treating the progress figure as a new attack count would conflate remediation and exploitation.
The time stamp matters because patching rates can move as hosting providers deploy updates. Figures collected on 26 October should not be presented as a current live measurement on 28 October without a fresh reading using the same method. Later datasets may also reclassify hosts as additional checks resolve uncertain configurations.
At the midday 26 October snapshot, Infrawatch still classified most externally visible PHP hosts in its dataset as unpatched. Its UK and Netherlands figures describe that moment; the later remediation position and the number of compromised production systems require separate evidence.
