Tags: Software care
The October 2026 PHP vulnerabilities put a familiar instruction – “patch immediately” – under pressure. New Zealand’s NCSC urged organisations to update affected systems, check with suppliers and consider disabling public-facing services if they could not patch promptly.5
For organisations responding to the alert, the practical questions were immediate: which services use PHP, who is responsible for updating them, and can the changes be made safely? How can I know my systems are safe, and communicate this to our stakeholders? The answers depended partly on decisions made long before the vulnerabilities became public.
Our first article explored how software care is changing as vulnerabilities multiply and response windows shorten. The PHP incident shows why that matters: keeping software supported and understood helps preserve the ability to act when an urgent update arrives.
The NCSC identified an important difference in the routes available to organisations. Supported PHP versions could receive the fix through standard updates. Older, end-of-life versions required custom source patches or fixes supplied through operating-system vendors.5
The scale and consequences of the catch-up work were striking. Among more than 19,000 .co.nz websites surveyed, over four in ten used versions too old to receive the fix through a standard update. They needed an upgrade or a fix supplied specifically for their older software.7 Finland restricted government web services as a precaution. The Japan Foundation took its website offline, then reopened with some functions still unavailable.3 4 Service owners faced a difficult choice: keep an affected service available or interrupt access to protect it.
Falling behind can make that choice harder. Staying current reduces the catch-up work teams must tackle during an emergency, giving them a clearer route to securing the service and keeping it available.
The PHP response shows how a security warning can interrupt access before any confirmed compromise. Older incidents reinforce the point that the condition of software can shape the damage and recovery that follow an attack.
In May 2017, the WannaCry ransomware attack locked NHS organisations out of computers and disrupted services across England. At least 81 trusts were affected, and NHS England estimated that more than 19,000 appointments were cancelled. In five areas, patients had to travel elsewhere for accident and emergency care.9 Investigators linked infection to unsupported or unpatched Windows systems. There had been earlier warnings, but no formal mechanism for establishing whether local organisations had acted on them. The consequences of incomplete upkeep reached people waiting for care.9
The British Library’s October 2023 cyber attack illustrates a different problem: how accumulated work can complicate recovery. Secure copies of its digital collections survived, but the Library lacked viable infrastructure on which to restore them. Some major applications were unsupported or would not work in the new, secure environment. Restoring access required systems to be modified, upgraded or replaced.10
If we had to restore our service tomorrow, what would stand in the way?
For service owners, this raises a practical question: if we had to restore our service tomorrow, what would stand in the way? Backups are part of the answer. So are supported software, compatible infrastructure and a tested recovery process. Work postponed during normal operations can become something that must be resolved before a service can return. The public cost then grows with every day that people cannot access what they need.
Our first article explored the growing volume of vulnerabilities, shorter response windows and expanding range of software that organisations need to care for. The PHP incident brings those pressures into a concrete decision about whether a service can remain available.
The NCSC’s 2026 Cyber Threat Report reinforces the wider point: organisations need to accelerate patching, address unsupported systems and ensure they have the people and resources to sustain a higher tempo of updates.12
Regular updates, supported software and clear responsibility give teams a better starting point when an urgent advisory arrives. They reduce the amount of unfinished work that must be tackled alongside the urgent fix.
For government, this makes software care part of sustaining public access. Its value lies partly in the choices it preserves: the ability not only to keep a service available to the people who need it, in the case of an emergency on the scale of PHP - but to know from the outset who’s responsible, to respond quickly, and to communicate the work to stakeholders.
