Code Red: Y2K Is Here

When the clock struck midnight on 1 January 2000, the planes stayed in the air, the cash machines kept dispensing notes, and the power grid held firm. Within a week, a consensus formed among newspaper columnists that the Year 2000 bug had been a mirage. In reality, as the United States Senate Special Committee on Y2K documented in its final report, midnight passed quietly only because governments and corporations saw the deadline coming years in advance, took it deadly seriously, and spent an estimated $100 billion in the United States and $300 billion worldwide rewriting their code before the calendar flipped.

7 weeks ago, on 26 September, I warned that artificial intelligence was bringing a software security crisis of the same shape and far greater magnitude. For 30 years, our digital infrastructure stayed standing on a fragile economic truce: skilled human vulnerability researchers cost $200 an hour, need sleep, and only have time to test a tiny fraction of the world’s software. Once language models dropped the cost of auditing code and building exploits to pennies on the dollar, 3 decades of hidden bugs were going to detonate at once.

Unlike in 1999, we had no fixed date on the calendar, nobody mobilised in advance, and over the past 7 weeks midnight arrived.

More than 78,000 software vulnerabilities have been disclosed in 2026 so far, exceeding the total number of vulnerabilities recorded in the first 17 years of the CVE system combined (1999 to 2015). Look at the foundational systems that have been broken open in just the 7 weeks since 26 September:

• Microsoft’s 2,500-Vulnerability Double Tap (13 October & 10 November): A normal monthly Microsoft security update fixes roughly 80 to 100 flaws. In October, Microsoft had to patch 1,407 vulnerabilities in a single day (78 rated Critical); inNovember , it patched another 1,093 vulnerabilities (63 Critical), including unauthenticated remote takeover flaws across Windows Active Directory, DNS, DHCP, Kerberos, and SQL Server.
• PHP2Shell (21 October): The maintainers of PHP, the language powering nearly 70% of websites on earth, shipped anemergency release forCVE-2026-109618 andCVE-2026-109619 , a pair of 22-year-old memory-handling bugs that allow an unauthenticated visitor to take control of a web server before a single line of website code even runs.
• The Linux Kernel and the Browser Blitz (14–27 October): Researchers using an AI multi-agent system uncovered a 9-year-old flaw in the Linux virtualisation layer (CVE-2026-74580 ) allowing virtual machines to escape onto their host server. Days later, Anthropicdisclosed that an internal Claude model had built a remote root exploit for a 10-year-old bug in the Linux kernel’s core internet networking stack (CVE-2026-98432 ), alongside 62 high and critical vulnerabilities in Google Chrome (including 13 full sandbox escapes) and a 1-click Safari bypass. Mozilla Firefox 160 followed on 10 November with 99 security fixes of its own, including another 13 sandbox escapes.
• OpenSSH, Kerberos, Apache, and React (5–14 November): In the past 10 days alone, OpenSSH shipped anemergency patch (10.6p2) for a 10-year-old bug (CVE-2026-123158 ) on Alpine Linux where typing any password longer than 256 characters logs straight into locked accounts; MIT patched21 vulnerabilities at once in Kerberos 5 (MITKRB5-SA-2026-001) , explicitly crediting “greatly increased scrutiny over the past few months from researchers employing large language models”;React Server Components (CVE-2026-126187) andApache HTTP Server (CVE-2026-119618) both patched critical unauthenticated remote code execution flaws; andApache Shiro (CVE-2026-129349) disclosed yesterday that turning on login caching allowed anyone to sign in with any password.

This is a Code Red for the internet, and our institutions are sleepwalking straight into it.

The 53-Minute Clock vs. the 30-Day SLA #

Inspect the actual code changes that fixed these vulnerabilities, and you find tiny, 1-line human oversights that sat in public codebases for a decade:

• The fix for the critical Apache web server bug changed 1 variable name on 1 line of code (req->headers tor->headers_in ), stopping concurrent web requests from overwriting each other’s memory.
• The fix for the Linux kernel networking bug added 4 letters (_rcu ) to 2 memory-cleanup lines written in January 2016, so one processor waits a few microseconds for another processor to finish reading a network packet before deleting it.
• The fix for the OpenSSH login bypass added a single check verifying that a stored password hash is at least 4 characters long, preventing a 1-character"" error code from matching the "" marker of a locked account.

For 20 years, 1-line mistakes like those stayed dormant because turning a subtle timing flaw into a working cyber weapon required weeks of painstaking human engineering. When Anthropic pointed Claude at that 2016 Linux networking bug, the model bypassed the kernel’s memory defenses in 48 minutes and achieved full remote root control 53 minutes after starting. Now compare a 53-minute exploit clock with how corporate and government IT departments actually operate.

Ask any bank, hospital, or government ministry to see its security policy, and you will be shown a document promising a “30-day Service Level Agreement” to patch critical vulnerabilities (and 60 to 90 days for high-severity flaws), after the patch has been reviewed by a weekly Change Advisory Board. Even the operating system vendors move at a crawl: the 2-line fix for the Linux networking bug was written on 1 October and published as a CVE on 15 October, yet Red Hat Enterprise Linux did not begin shipping patched kernels until November, and Canonical’s Ubuntu LTS (USN-9018-1) did not ship its patched kernel until 10 November, a full 40 days after the fix was written and 14 days after Anthropic announced to the world that an AI model could weaponise the bug in 53 minutes.

When attackers weaponise flaws in 53 minutes and defenders patch on a 30-day schedule, the outcome is mathematically certain. My prediction for the coming 12 months is that we are going to witness a catastrophic public-sector data breach: Whitehall losing a core tax or benefits database, or the NHS losing tens of millions of patient medical records. Government ministries and hospital trusts run sprawling estates of legacy software governed by committee sign-offs and 30-day patching targets. In the world that just arrived, a 30-day patch window is an open invitation.

There Is No Safe Way to Hold Crypto #

If you want a preview of what happens when a high-value target meets this new reality, look at cryptocurrency over the past month. Crypto is the ultimate stress test for computer security because transactions are irreversible and every wallet is a public bounty. Whenever someone loses their coins, crypto enthusiasts insist that the victim simply chose the wrong storage method. Over the span of 3 weeks, all 3 ways of holding cryptocurrency failed at once:

1. Centralised custodians (”Leave it with the exchange”). On 29 October, North Korean hackers compromised a single DevOps engineer’s laptop at Binance, pivoted into internal signing containers, delegated wallet control to bypass normal multi-signature checks, anddrained $6.3 billion in 20 minutes , the largest cyber heist in history.
2. Software wallets (”Hold your own keys on your laptop”). Keep your keys in a browser or desktop wallet on your own computer, and your money is only as safe as your web browser and operating system. On 27 October,Anthropic showed that visiting a single malicious web page on a stock MacBook was enough for a Claude-written exploit chain to break out of Chrome’s or Safari’s security sandbox in seconds and execute arbitrary commands on the underlying machine where your wallet lives.
3. Hardware wallets (”Offline cold storage”). Buy a dedicated physical device so your keys never touch your computer, and you are at the mercy of the physical supply chain. On 15 October,Ledger confirmed that an organised crime ring had opened genuine Ledger wallets in the retail distribution channel and soldered a tiny circuit board with a cellular eSIM behind the screen. Ledger’s internal security chip passed every cryptographic authenticity check while the parasite chip read users’ 24-word recovery phrases off the display during setup and texted them over the mobile phone network to drain over $100 million.

There is no secure way to hold crypto. Even if you stamp your recovery phrase onto a sheet of titanium and bury it in a concrete bunker, security in crypto is a shared liability. When traditional bank fraud occurs, the bank’s capital and insurance absorb the hit and the pounds in your account keep their purchasing power. When billions are stolen from exchanges and hardware wallets, confidence in the entire crypto ecosystem erodes and token prices fall, which means you lose money even when your own wallet isn’t hacked.

Legacy Baggage in Modern Clouds #

How do we fix software infrastructure so that normal businesses and hospitals aren’t permanently losing a race against automated exploit generators?

Beyond compressing patch latency from 30 days to a few hours, we have to rethink what we put on our servers in the first place.

Ask yourself why a modern cloud server running a single web application is vulnerable to bugs in file-sharing drivers, multi-user login services, and obscure networking extensions. The answer is historical inertia. The Linux operating system was designed in 1991 for a physical server sitting in a university basement, shared by dozens of human users logging in simultaneously with passwords, plugging in printers, mounting shared drives, and running dozens of different programs at once. Over 35 years, Linux grew into a 30-million-line Swiss Army knife built to support every piece of hardware and every workflow invented since the George H. W. Bush administration.

Today, a cloud virtual machine does one job, such as running a single web service on virtualised hardware. Yet out of habit, inside every single virtual box we still boot the entire 30-million-line 1991 operating system, complete with user accounts, administrative shells, and thousands of drivers nobody in the cloud ever uses.

That is why the unikernel approach is about have its moment. A unikernel throws away the 99% of a traditional operating system that a single-purpose cloud server never touches. Instead of booting a full multi-user operating system and running your program on top of it, a unikernel packages your program together with only the tiny handful of networking and memory routines it actually calls. There are no user accounts to hijack, no command-line shell for an attacker to type commands into, and roughly 20,000 lines of code to defend instead of 30 million.

Once you shrink the software down to its essentials, the same AI revolution that created this crisis gives defenders the ultimate weapon: formal verification, using mathematics to prove that a piece of software has zero bugs of a given class, the way a mathematician proves a theorem in geometry.

For decades, formal verification was far too expensive for commercial software. As Jane Street’s Yaron Minsky wrote in a landmark essay in June announcing that his firm had reversed 25 years of scepticism to build a dedicated formal methods team, mathematically proving the correctness of a tiny, 8,700-line operating system kernel (seL4) by hand took 25 person-years of PhD labour, or half a day of human work for every single line of code. Coding agents transform that arithmetic, and formal verification is also going to finally have its moment. A human engineer defines (or at least reviews) the safety rules, the AI agent grinds out the thousands of lines of mathematical proof, and a deterministic proof-checker verifies the maths in seconds. Ordinary software tests only check that a program works on a few sample inputs; a formal proof guarantees that the code holds up across every possible input.

Assume the Counterparty Is Breached #

Automated hourly patching, unikernels, and formally verified code will eventually make the cloud far more resilient than it is today. Until that transition happens, ordinary people have to live in the old world.

From today onwards, a safe working assumption as an individual is that every organisation holding your data will eventually be breached, with the possible exception of the hyperscaler Big Tech platforms (Google, Apple, AWS, and Microsoft) that possess the engineering muscle and automated infrastructure to patch and defend themselves at machine speed. Operate on the basis that every hospital clinic, law firm, local council, accounting practice, and mid-market software vendor running a 30-day patching cycle is going to leak its database sooner or later. Act accordingly:

1. Never reuse a password across websites. Let a password manager generate a unique random password for every account, backed by 2-factor authentication, so that when a minor website you used 3 years ago gets breached tomorrow morning, the attacker cannot use that password anywhere else.
2. Think before you type. Treat every web form and document upload at a normal institution as if it were a public noticeboard. If you don’t strictly need to hand over a sensitive personal detail, medical history, or identity document to a third party, keep it off their servers.

The Unseen Cost of Panic #

There is one last danger sitting underneath this wave of vulnerabilities, and it worries me more than the breaches themselves.

When that inevitable mega-breach hits the NHS or a major government ministry over the coming year, no cabinet minister or chief information security officer is going to stand in front of the television cameras and say: “We lost 50 million records because we ran a bloated 1990s operating system on a 30-day patching schedule.” They are going to blame “rogue AI cyber weapons”, and call for emergency regulations to slow down, license, and restrict artificial intelligence development and adoption.

That reaction will be a catastrophe, because of the classic asymmetry between what is seen and what is unseen.

When a database is breached, the cost is on the evening news the next day. When Western governments overreact by throttling the development and adoption of AI, the costs are diffused, unmeasured, and far larger: slower productivity growth, delayed medical and scientific research, and a domestic economy locked out of the most important general-purpose technology of the century. Unilateral restraint only binds the jurisdictions that choose to pass the rules, which means Western regulators will simply hand the technological lead to adversarial states that have no intention of slowing down.

The vulnerability flood of the past 7 weeks is a software engineering problem caused by 30 years of deferred maintenance, and it has a software engineering solution: shrink the stack, automate the patch pipeline, and use AI to verify the code. We need to fix our digital plumbing at full speed today, before a preventable breach scares politicians into taxing the future to protect yesterday’s bad code.