A website can be taking orders and answering enquiries perfectly well, until its hosting provider announces an urgent security update. If the software behind the site is too old to accept that update safely, the business faces an uncomfortable choice: risk leaving it exposed, or take it offline while the problem is addressed.
That dilemma became very public on 21 October 2026, when two critical vulnerabilities in PHP, the programming language behind platforms such as WordPress and Drupal, prompted an international security response. Roled covered the emergency release at the time. The more lasting story is what the incident revealed about website maintenance.
Why so many websites went offline
The flaws, CVE-2026-109618 and CVE-2026-109619, could allow an attacker to run code on a vulnerable server without logging in. The PHP project issued fixes for supported versions on 21 October and urged immediate updates.
The consequences were visible far beyond the developer community. Reuters reported precautionary shutdowns affecting government websites and online services across Europe and beyond. In Britain, The Guardian reported that 32 government services had been taken offline, largely while protective work was carried out. The story quickly moved from technology publications into international news coverage.
Taking a website offline was not evidence that it had been hacked. In many cases, it was a deliberate safety measure. The UK's National Cyber Security Centre advised companies that could not promptly apply fixes or suitable temporary precautions to consider removing affected services from public access. Across the industry, maintainers prepared patches, hosting providers distributed updates and security companies deployed extra protections. Those defences helped buy time, but did not replace fixing PHP itself.
The hidden problem: a website that works but cannot change
PHP runs on the server, beneath the content management system. Updating WordPress or Drupal from its administration screen does not automatically update PHP. Equally, a hosting company may keep the server patched without being responsible for resolving a site's incompatible plugins or custom functionality.
This distinction matters most for older websites. A site may have depended on the same PHP version for years because changing it would break an extension, a payment integration or some custom code. The longer that situation continues, the more an emergency upgrade can resemble a rushed rebuild.
Not every site taken offline during the PHP incident was unable to upgrade; many were paused briefly as a precaution. Nor does every security patch require a risky move to a new major PHP version. But when a site depends on software that has reached the end of support, finding a safe, timely fix can become much harder.
PHP 7.4 received a patch, but there is a catch
One encouraging part of the response came from cPanel, a widely used hosting control panel. Its official advisory, updated on 22 October, lists a patched EasyApache 4 PHP 7.4 package: ea-php74 7.4.33-19. For websites unable to move immediately to a newer PHP branch, that vendor backport could provide a safer route through the emergency.
There is a difference between a patched package and a supported language version. PHP 7.4 reached end of life in November 2022. The cPanel patch applies to the relevant vendor package, not automatically to every server running PHP 7.4, and it does not make all the other risks of ageing software disappear. Other suppliers have their own packages and update schedules.
A backport can be a valuable bridge. It should give a business time to plan compatibility work, rather than become an excuse to postpone it indefinitely. The sensible question is whether the particular server has received a verified fix, not whether its PHP version number looks reassuring.
AI has changed the security race
There was another unusual feature of the PHP story: artificial intelligence helped researchers demonstrate weaknesses that had resisted conventional investigation. OpenAI reported that security firm Calif used GPT-5.6 Sol in its research, while Wiz independently used AI-assisted methods to identify related problems. The PHP Foundation's account says signs of one underlying flaw had first emerged in 2024, but work on a fix stalled amid difficult technical trade-offs and limited resources.
That is a compelling example of AI helping defenders. The same capabilities could also help criminals analyse updates, search for vulnerable installations and develop attacks faster. It would be misleading, however, to claim that AI was responsible for the attacks observed in this incident without evidence.
The Foundation also described the less glamorous side of the AI boom: more than 100 recent security reports that were invalid, duplicates or could not be reproduced. Tools can accelerate discovery, but people still have to validate the findings, decide how to fix the software and coordinate its release. That work depends heavily on experienced, often overstretched open-source maintainers.
Being ready is more useful than reacting perfectly
The most useful preparation is not a promise of zero downtime. It is an agreed way to update important systems without having to uncover years of technical decisions during an emergency.
- Know which PHP version and other major software components your live website uses, including any vendor-provided security backports.
- Make responsibilities explicit: who patches the hosting environment, who maintains the CMS and custom code, and who can approve emergency action?
- Keep a suitable test environment, working backups and a recovery plan. After an update, check enquiries, payments, bookings and integrations, not just the homepage.
- Review unsupported components before an emergency forces a choice between prolonged downtime and an unsafe system.
For companies that do not have an internal technical team, ongoing support can make those responsibilities easier to manage. Roled's Website Care covers ongoing website maintenance and monitoring, while its optional Managed Hosting specifically includes server updates and patching. Keeping those two layers coordinated is often more useful than treating hosting and website maintenance as unrelated tasks.
If this incident has raised questions about your own website, start with a practical one: could your provider tell you today exactly which PHP security fix is installed, and what has been tested since it was applied? A clear answer is a far better sign of preparedness than a website that merely appears to be working.
