The flaw was found. Then what?

On 21 October 2026, a vulnerability became public in PHP, the programming language that runs roughly seven in ten websites on the internet, according to the W3Techs usage survey. The Guardian reported that governments in Belgium, the Netherlands, Finland, France and Germany took their own websites offline while they patched, that the Wikimedia Foundation pulled several systems as a precaution, and that the US National Security Agency advised any organisation that could not patch immediately to disconnect. The UK's National Cyber Security Centre gave the same advice and added a specific instruction to check for backdoors left by an attacker.

Two days later, on 23 October, the Guardian ran the story under a name the industry had already given the month: "Black October". The quotes were blunt. Sam Altman: "I no longer think we're going to be able to patch all bugs." Anthropic's deputy chief information security officer, Jason Clinton, predicted a "vulnerability tsunami". Cloudflare's chief executive, Matthew Prince, said the next two years would "feel like the sky is falling". The mechanism behind the alarm is the one worth understanding, because it is not about this particular flaw. It is about the cost of finding flaws, which has collapsed, meeting the cost of fixing them, which has not.

What actually changed

For thirty years, finding a serious flaw in widely used software was expensive. It took a skilled person, weeks of work, and a fair amount of luck. The economics were simple: attacks were rare relative to defences because attacks were hard.

That ratio has moved. A model that can read code, run it, and look for the specific patterns that produce exploitable behaviour is patient, parallel and cheap. It does not get bored at hour nine. It does not stop at the first thing that looks fine. It can be pointed at every dependency a firm relies on, all at once. The PHP flaw that became public on 21 October was found by researchers testing cyber defences, and the reporting is explicit that AI tools were used to help identify it.

Fixing, though, has not sped up at the same rate. A patch has to be written by a person who understands the system, reviewed by someone else, tested against everything that depends on it, and deployed without breaking the businesses running on it. That is sequential, human and slow. It has always been the bottleneck. The change in 2026 is that the discovery side of the equation got much faster, so the bottleneck got more visible.

The Guardian's 23 October piece notes that exploitation attempts had already begun within a day of the flaw becoming public, which is the other half of the asymmetry: once a patch is public, the flaw is public too, and AI tools can reverse-engineer the bug from the patch with little effort.

Three places the loud version breaks

The conclusion a lot of people draw from this is that the internet is one bad month away from going dark, and that the sensible response is to prepare for weeks without power, water or payments. That is a real fear and it is being sold hard. It is also wrong in three specific ways, and the three ways matter because they change what a firm should do.

The internet does not fail as a single object. It has no switch. It is thousands of independently operated networks that route around damage, which is the property that has let it survive every outage to date. What fails is not the network but the concentration inside it: the domain name system, the routing tables, a handful of cloud providers, one dominant payment rail, one widely used library. The realistic failure is not "the internet is gone". It is "the one service everything depends on is gone for thirty-six hours". Those are different problems with different answers.

Almost every serious incident has a warning phase. Heartbleed in 2014, WannaCry in 2017, Log4shell at the end of 2021. In each case the flaw was known, a patch existed, and the damage was concentrated in the organisations that had not yet applied it. The historical record is not a single silent catastrophe. It is a run of expensive, ugly, survivable events, each of which taught the next round of defenders something. The PHP flaw fits that pattern: it was found, patched, and the fallout is being managed, not the end of the network.

Counting flaws is not the same as measuring danger. More scanners, faster disclosure, better tooling and AI-assisted triage all push the reported number up. Some of that increase is real exposure. Some of it is that we have become much better at finding what was always there. A headline number quoted without saying which of those two it is has told you nothing useful. The honest reading of October 2026 is that the next few years will contain more outages, more often, and that they will mostly be survivable and expensive rather than terminal.

The question that actually matters for a firm

Here is where the abstract becomes a business decision.

Every firm of any size now runs on a stack of dependencies it does not control: a payment provider, an email provider, a hosting account, a cloud service, a handful of software subscriptions. When one of them fails, the firm does not lose its data or its building. It loses time. The takings stop while the costs carry on, and the length of that gap, not the probability of the failure, is what determines whether a bad week becomes a lost month.

That gap is the only part of the problem a firm can actually control. You cannot patch the world's software. You cannot choose the day. You can decide, in advance, how quickly you notice, how quickly you decide, and how quickly you are trading again. That is a recovery-time problem, and it is solvable with a page of writing and about twenty minutes of honesty.

The UK government spent October telling households to be ready for three days without help, on a checklist that recommends nine litres of water per person, tinned food and a battery radio. The BBC reported the advice on 24 October, alongside a National Audit Office warning that the food supply chain is exposed to cyber-attack and climate risk. That is the physical version of the same argument. The digital version, for the firm rather than the household, is the one nobody has written the checklist for. This is that checklist.

Seven checks, in order of cost if missing

Name the single points of failure. One card terminal, one email provider, one hosting account, one person who holds the passwords. On one page.

Test a restore, not a backup. Ask how long a restore takes and who performs it. An untested backup is a hope.

Keep an offline copy of the money documents. Customer list, open invoices, key contracts, supplier contacts, on a device the firm controls.

Have a second way to communicate. A phone number and a message group that do not depend on the work email.

Be able to take a payment and issue a document offline. Cash float, paper invoice pad, a written record of what was agreed.

Three days of water and food at home. The government's own advice, and cheap.

Write the one page. If this breaks, we do that. Who calls whom. What pauses. What customers are told.

None of it requires a generator, a bunker or a subscription. All of it is checkable in an afternoon. The firms that come through an outage well are rarely the ones that spent the most. They are the ones that had already decided what they would do.

Where this sits

This is the same discipline as the European Technology Risk Assessment: read the exposure honestly, name what is actually at stake, and decide the response before the event rather than during it. The ETRA looks at that question across a region. This looks at it across a single firm.

If you run a business of between five and fifty people, the seven checks are on one printable page, free, at fleurlamont.com/ebook.html. Keep it by the till. The point is not to predict the bad day. It is to make the bad day short.