Blog · Cyber Security · Tech

Black October and the time left to decide

26 October 2026 · by Interlogica

On Wednesday 21 October, within a few hours, public bodies and universities in the Netherlands, Finland and Austria switched off their websites before the fix they needed was even available. They had not been breached: they had read the US NSA’s advice that anyone running PHP should update immediately or take their systems offline until they could, and they chose the second option.

Several observers have already called it “Black October”, and the temptation is to tell the story as a list of vulnerabilities. We think it is more useful to look at it from another angle, because what has really changed is not the code but the time an organisation has to decide what to do.

What happened, in short

The main story is PHP2Shell: two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10) in the PHP engine, present from version 5.4 to 8.5, that let an unauthenticated attacker run code on the server. The flaws were announced on 20 October and fixed versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) shipped the following day; the scale comes from the fact that, by some estimates, PHP runs behind around 70% of websites, including WordPress, Drupal and Magento.

Other incidents piled up around PHP2Shell. Between 17 and 19 October someone breached the infrastructure of TeamUpdraft, maker of UpdraftPlus, a WordPress backup plugin with more than four million installations, and used the stolen remote-management keys to install at least 99 backdoored plugins on connected sites. On 21 October version 1.107.0 of LiteLLM, a widely used library that connects applications to AI models, was published with credential-stealing malware, after attackers used tokens stolen from three engineers. The same day Node.js fixed four serious vulnerabilities, while browsers and operating systems blocked eight intermediate certificates from the Indian authority eMudhra, whose private keys were weak enough to be reconstructed almost instantly.

On smartphones the news was a trend rather than a single flaw: researchers at iVerify and Report URI described campaigns using online advertising to install spyware on iPhones, aimed no longer at journalists or politicians but at the credentials and crypto wallets of ordinary people.

Time has shrunk

The most instructive part is the timeline. Amazon detected a first PHP2Shell exploitation attempt on 17 October, four days before official disclosure, and after the announcement Cloudflare saw attack attempts jump from thousands to millions within hours; at the same moment CISA said it had not yet observed exploitation, a reminder of how hard it is, even for professionals, to know for sure what is going on while it happens.

The PHP flaws were found with the help of AI models, and OpenAI is among those who reported them. Speaking to CNBC, Chris Krebs, former director of CISA, put the moment in perspective:

Around 3% of all critical vulnerabilities ever discovered have surfaced in the last month.

We do not yet know whether this is a spike or the new normal, but the direction is clear: the same technology that helps find defects also shortens the distance between finding a flaw and someone trying to use it.

For years vulnerability management has run on calendar time, made of maintenance windows, release cycles and weekly meetings. A week like this one shows that those timescales no longer hold, and that the bottleneck, very often, is not technical.

The real problem is deciding

Applying a PHP patch is a known operation. Deciding to switch off the site you sell through, your customer portal or the system a hundred people use every day, perhaps at night and with incomplete information, is something else: it is a business choice with a certain, immediate cost, weighed against a likely but unproven risk.

Taking a public website offline within hours, as the Dutch and Finnish bodies did, requires someone with the authority to do it and enough context to do it well. In many organisations the person who sees the alert has no power to decide, and the person with the power lacks what they need to judge; by the time the two have talked, the window has closed.

It is the same theme we meet whenever we talk about autonomy and delegation.

Delegating does not mean handing out tasks, it means distributing decision-making capacity.

And distributed decision-making only works if it is prepared in advance: who can decide what, by which criteria, within which limits and with what responsibility. When the emergency arrives, it is too late to settle that.

There is a second, less visible lesson. The UpdraftCentral and LiteLLM cases are about components we trusted without really looking at them: a remote-management key switched on by default, a library that concentrates access keys to many AI services in one place. You cannot inspect everything, but you can at least know what you are running, because nobody can decide quickly about something they do not know exists.

What to do now

If you run websites or systems, a few concrete checks are worth more than any reflection:

  • check which PHP versions run on your servers, including the forgotten ones, and update to the fixed releases;
  • if you use UpdraftPlus connected to UpdraftCentral, update the plugin and manually delete the connection keys, because updating alone does not remove a backdoor already installed;
  • if LiteLLM 1.107.0 was installed in your environments, treat those machines as compromised and rotate credentials;
  • update browsers, operating systems and smartphones to the latest version available.

Then, once the emergency is over, it is worth asking an organisational question rather than a technical one: next time, who in your organisation can decide within an hour to switch a system off, and do they know they can?

Sources

Back to the list