Zero-Day Hero: How a Bug Is Found, Named and Finally Patched

There is a machine on a shelf somewhere in your organisation that has not been rebooted since a prime minister ago. It runs something with a green-on-black interface, it does exactly one important job, and the last person who fully understood it left in 2019 with a cake and a card. Every few weeks a small red badge appears on somebody's screen: updates available. Every few weeks somebody, reasonably, decides that today is not the day to reboot the thing that has never once failed. The badge is dismissed. The machine hums on.

I want you to hold that red badge in your mind, because on 7 April this year it stopped being a minor act of workplace procrastination and became, quietly, one of the most dangerous decisions in your building.

That was the day Anthropic announced Project Glasswing, an initiative built around a new model, Claude Mythos Preview, that the company gave to a small, gated group: a dozen launch partners including Apple, Microsoft, Google and the Linux Foundation, and forty-odd other organisations that maintain the software the world runs on. The reason for the small group is the uncomfortable part. Anthropic says the model "has already identified thousands of zero-day vulnerabilities across critical infrastructure". Not thousands of theoretical weaknesses. Thousands of real, previously unknown ways into real systems, found by a machine, in a matter of weeks.

Take a breath. Nobody is coming for the machine on your shelf tonight, specifically, and this is not a story about software waking up and turning nasty. It is a story about a very old thing—the humble software bug—suddenly meeting a very new thing that can find it a thousand times over before breakfast. And the only way to understand why that matters, and what to actually do about it, is to follow one bug through its entire life: how it is born, how it is found, how it gets a name and a number, how the world is told on a strict and slightly bureaucratic clock, how it is patched, and then the slow, unglamorous, deeply human business of that patch reaching the machine on your shelf.

By the end you will be able to explain a zero-day to a nervous board member in one sentence, and, more usefully, set a patch policy that is neither "panic" nor "next quarter". Let's get into it.

Part 1: The Life of a Bug, From the Loose Stone Up

Start with something you already do, and already have a feeling about, even if you have never named it. You put off an update.

You know, dimly, that the update is closing a hole. You know that the hole was there yesterday, and the day before, and probably for years, without anything bad happening. So the update feels less like locking a door and more like being told your door has, technically, always been unlockable, and would you mind stopping everything to fit a new one. The gap between "the hole exists" and "someone walks through it" feels enormous. Most days, it is. This whole article is about the days it is not.

Let me build the idea up in layers, because the word "zero-day" gets thrown around to mean everything and therefore nothing.

A vulnerability is the loose stone in the wall. It is a flaw in software that lets someone make it do a thing it was never meant to do: read data they should not see, run a command they should not be allowed to run, or simply knock the whole thing over. Most vulnerabilities are boring mistakes. A programmer assumes a piece of incoming data will be at most a hundred characters long, and reserves exactly a hundred characters of space for it. One day something sends a hundred and one, and that extra character lands somewhere it should not, and the machine does something the programmer never imagined. That is a real and famous class of bug, and we will meet a seventeen-year-old example of it, in FreeBSD, shortly.

An exploit is not the loose stone; it is the crowbar shaped precisely to lever it out. A vulnerability is a possibility of misuse. An exploit is the actual, working tool that misuses it: the specific booby-trapped file, the exact sequence of network packets, the crafted web page. It is what turns a flaw into a foothold—the thing that lets someone read data they should not, or quietly steal a logged-in session and walk around your systems wearing a real user's identity. This distinction matters more than any other in the article. A wall can have a loose stone for decades with no crowbar in the world shaped to fit it. The danger is not the flaw alone. It is the flaw plus a working tool, in someone's hands.

A zero-day is the name we give a vulnerability that the people responsible for fixing it have had zero days to work on—because they do not yet know it exists. The clock in the name is the defender's clock, and it reads zero. If a stranger has found the loose stone and shaped a crowbar, and the town has no idea, that is the most dangerous state a bug can be in. There is a fix ready: none. There is a warning out: none. The only people who know are the ones who might use it.

The opposite of a zero-day is, sensibly enough, an N-day: a bug that has been public and patched for some number of days—N of them. You would think a patched bug is a safe bug. It is not, and the reason why is the hinge this whole article turns on, so I will come back to it with some force in Part 3. For now, hold the shape: a bug's life runs from zero-day (secret, unfixed, most dangerous to you if the wrong person found it) through the moment of a fix, into N-day (public, fixed, and dangerous to you only for as long as you have not installed the fix).

That last clause is the one everyone forgets. A fix that exists is not a fix that is installed. The red badge on the machine on your shelf is the gap between the two, made visible.

Part 2: The Paperwork of a Broken Thing

A bug found in secret is a private problem. A bug the world needs to coordinate around needs, first, a name—because you cannot fix, discuss, prioritise or warn about a thing that everyone calls something different.

max_tokensPOST./v1/messages

The number: CVE

When a new vulnerability is going to be made public, it gets a CVE identifier. You have seen these: CVE-2026-4747 is one we will meet properly in Part 4. CVE stands for Common Vulnerabilities and Exposures, and the idea is gloriously unglamorous. It is a filing system. The CVE Program's stated mission is "to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities", with "one CVE Record for each vulnerability in the catalog". That is the whole job: give every bug a unique, boring number, so that a security team in Hobart, a vendor in California and an attacker in a basement can all be certain they are arguing about the same loose stone.

The numbers are handed out by organisations called CNAs (CVE Numbering Authorities): vendors, open-source projects and coordination centres that have been authorised to assign identifiers within their own scope. Mozilla is a CNA; so is the FreeBSD project. The programme itself is sponsored by the US cybersecurity agency, CISA, and the list has long been operated by the non-profit MITRE.¹ It is, when you look closely, a piece of shared public infrastructure held together with a surprisingly small amount of money and a great deal of goodwill—a bit like the software it catalogues.

The severity: CVSS

A number tells you which bug. It does not tell you how bad. For that there is a second piece of paperwork, the CVSS, the Common Vulnerability Scoring System, which turns a bug's technical shape into a number from 0.0 to 10.0. The current version 4.0 describes CVSS as capturing "the principal technical characteristics of software, hardware and firmware vulnerabilities". The score lands in a band with a word attached: 0.1 to 3.9 is Low, 4.0 to 6.9 Medium, 7.0 to 8.9 High, and 9.0 to 10.0 Critical. Log4Shell, the vulnerability that had every engineer on Earth working through a December weekend a few years ago, scored a clean 10.0.

Here is the first trap, and it catches out even careful teams. A CVSS score measures how bad a bug is if it is exploited. It says nothing about whether anyone actually is. It is the difference between a doctor telling you a disease is severe and telling you it is going around. A "Critical" bug in a component you do not use, that no attacker has ever bothered with, may deserve less of your Tuesday than a "Medium" bug that criminals are cheerfully using right now. Severity is not the same as risk, and the whole of our practical section in Part 6 rests on keeping the two apart.²

The odds: KEV and EPSS

So the industry built two more instruments, both of which answer the question CVSS refuses to: is anyone using this?

The first is a list. CISA keeps the Known Exploited Vulnerabilities catalog, which it calls "the authoritative source of vulnerabilities that have been exploited in the wild". To get on it, a bug must meet three tests: it has a CVE ID, there is reliable evidence it is being actively exploited, and there is a clear fix to apply. The KEV is a stark and useful thing. If a bug is on it, the argument is over—someone is walking through that gap, right now, and you patch.

The second is a forecast. The EPSS, the Exploit Prediction Scoring System, run by the security body FIRST, is "a daily estimate of the probability of exploitation activity being observed over the next 30 days" for every published CVE. Where the KEV tells you the house is already on fire, EPSS is the smoke detector giving you a probability. It exists because the raw numbers are brutal: CISA itself has noted that "less than 4% of the total number of CVEs have been publicly exploited". Patch everything with equal urgency and you spend ninety-six per cent of your effort on doors nobody is trying. The point of EPSS is to spend it on the four per cent that matter.

Three instruments, three different questions. CVSS: how bad if it happens? KEV: is it happening? EPSS: how likely to happen soon? Keep those three apart in your head and most of modern patching strategy falls into place. Blur them and you will either drown or get breached, sometimes both.

Part 3: The Ninety-Day Clock

Now the awkward middle of a bug's life. Someone who is not a criminal has found the loose stone. What are they supposed to do with it?

This is genuinely hard, and reasonable people have fought about it for twenty years. Tell the world immediately, and you have handed every attacker a map before the vendor can cut a new stone: that is called full disclosure, and it is a fine way to get people hurt. Tell only the vendor and then keep quiet forever, and you are trusting them to fix it on their own schedule, which historically has meant "never", because nothing focuses a company like a public deadline. The answer the industry has mostly settled on sits between the two, and it is called coordinated disclosure: you tell the vendor privately, you agree a deadline, and you go public when the deadline arrives, patched or not.

The most influential version of that deadline comes from Google's Project Zero, an elite bug-hunting team whose disclosure policy half the industry has quietly adopted. Their 2021 "90+30" policy gives a vendor 90 days to ship a fix, then a further 30 days for users to install it before full technical details go out. If the bug is already being exploited in the wild, the clock compresses to 7 days. A vendor that is close but not done can request a 14-day grace period. Anthropic's own disclosure principles for the bugs Mythos finds read almost identically: a 90-day default, a 14-day extension on request, a 7-day target for actively exploited critical bugs, and a wait of 45 days after a patch ships before publishing the technical details, "to give downstream users time to deploy the fix".

stop_reasoneval:.pass

Notice what all these numbers are quietly admitting: that the danger does not end when the patch ships. It moves.

The N-day window, or why a fixed bug bites

Here is the piece that surprises people, and it is the most important idea in the article, so I am going to slow right down.

The moment a vendor releases a patch, they also, unavoidably, publish a map to the bug. A patch is a change to the code, and anyone can look at what changed. "Ah," says the attacker, reading the fix, "so that line was the loose stone." The patch closes the hole, yes—but it also points a large, well-lit arrow at where the hole used to be. This is why a SANS and Cloud Security Alliance briefing this month says, flatly, that "every patch also becomes an exploit blueprint".

So the day a fix ships, a new race begins. On one side, defenders scrambling to install the patch across every machine they own. On the other, attackers reverse-engineering that same patch into a working crowbar and hunting for machines that have not yet applied it. Every one of those machines—every one still running the old code—is now more exposed than it was the day before the fix existed, because now the weakness is public. This is the N-day window, and it is where a genuinely enormous share of real-world damage happens. The bug on the machine on your shelf is at its most dangerous not while it is secret, but in the days and weeks after the world is told how to fix it and you have not.

CISA's own figures, from the directive that created the KEV catalog, make the speed of that race vivid. Of the small share of vulnerabilities that do get exploited, it found that "42% are being used on day 0 of disclosure; 50% within 2 days; and 75% within 28 days". Half of all exploited bugs are under attack within two days of becoming public. Your patch window, for the ones that matter, is measured in hours.

That was already the state of play. Then the finding got automated.

page_viewtool_use

Part 4: The Machine That Reads Every Wall at Once

For the whole history of software, the loose stone in Part 1 had a natural protection that had nothing to do with how well it was hidden: finding it was expensive. A serious vulnerability in a well-audited system is, almost by definition, subtle—the obvious mistakes were fixed years ago. Prising out a new one took a scarce and costly human expert, weeks of patient staring at code, and a fair amount of luck. That expense was, in effect, a wall around the wall. There simply were not enough elite bug-hunters in the world to check every line of every program. Most loose stones sat undisturbed because nobody had the time to look.

This is the same capability I wrote about in red teaming AI systems, only turned outward: instead of a team probing a model for its weaknesses, a model probes the world's code for its own. The first crack in that wall came, fittingly, from an AI research team, and it was pointed the friendly way. In late 2024 Google's Project Zero and DeepMind reported that their experimental agent, Big Sleep, had found what they called "the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software": a bug in SQLite, a database engine that runs inside a staggering amount of the world's software. They caught it before it shipped in a release. Their framing was pure optimism, and worth quoting because it is the hopeful half of this whole story: "Finding vulnerabilities in software before it's even released, means that there's no scope for attackers to compete: the vulnerabilities are fixed before attackers even have a chance to use them."

utm_source=SELECT

Then, in April this year, that experimental capability arrived at industrial scale. The Frontier Red Team's technical writeup behind Project Glasswing is one of the more sobering documents I have read in this field, and its specifics are what make it real rather than hype. The team ran Mythos Preview as an automated bug-hunter across critical open-source code, and the examples they were able to disclose—more on that qualifier in a moment—include some genuinely venerable stones:

• A 27-year-old bug in OpenBSD, an operating system whose entire reputation is built on being secure. It was a flaw in how the system handled a common network optimisation, and it let an attacker crash the machine remotely. You can confirm the fix independently: OpenBSD's own errata list records, for 25 March 2026, that "TCP packets with invalid SACK options could crash the kernel". Twenty-seven years, in a codebase people trust because it is scrutinised.
• A 16-year-old bug in FFmpeg, the media library that quietly decodes video almost everywhere, and one of the most heavily fuzz-tested projects in existence. The model found a flaw in its handling of the H.264 video format that every previous tool and human reviewer had missed.
• A 17-year-old remote-code-execution bug in FreeBSD that hands an unauthenticated attacker complete control of a server. This one is a matter of public record: it is CVE-2026-4747, and the FreeBSD advisory credits it, in plain black and white, to "Nicholas Carlini using Claude, Anthropic". The model found the loose stone and then forged the crowbar too, writing a complete working exploit with no human help after the first prompt.

The economics are the part that should keep a defender up at night. Anthropic reports that the thousand automated runs that found that OpenBSD bug, along with several dozen other findings, cost "under $20,000" in total. The single run that found the bug cost under fifty dollars, although, as the team notes, you only know which run will succeed in hindsight. The scarce, expensive human expert—the wall around the wall—has been replaced by something you can rent by the hour and run in parallel across every file at once. The report's conclusion opens with a famous line from open-source culture and turns it slightly menacing: "given enough eyeballs, all bugs are shallow." The catch is that the eyeballs are now infinite.

And here is the qualifier I promised, the one that reframes the whole "thousands of vulnerabilities" headline. Anthropic notes that "over 99% of the vulnerabilities we've found have not yet been patched", so they cannot responsibly describe them. The handful above are the ones already fixed. They are, explicitly, the visible sliver of a very large iceberg—which is exactly why the model was released to a locked room of a dozen launch partners and some forty other trusted organisations rather than the open internet.

Because that is the genuinely double-edged thing about this capability. The same machine that lets Mozilla's defenders find their own bugs first lets an attacker find them first instead. Which side gets the advantage depends entirely on a race—and the race is decided not by who can find the bug, but by who can respond to it. Which brings us to the slow, unfilmable, decidedly un-heroic half of the story.

Part 5: The Slow Half Nobody Films

Finding a bug is now cheap, fast and, frankly, a bit glamorous—there is a reason "hacker finds flaw" makes headlines. Fixing a bug, and then getting that fix onto every machine that needs it, is expensive, slow and about as photogenic as filing. This mismatch is the single most important thing to understand about the moment we are in, so let me put it as plainly as I can: AI has made the finding far faster without making the fixing meaningfully faster at all.

aria-labelgtm.js

The clearest illustration comes from the friendliest possible use of this technology. When Mozilla was given an early version of Mythos Preview to harden Firefox, the result was extraordinary: Firefox 150 shipped with fixes for 271 vulnerabilities that the model had surfaced, after an earlier scan with a previous model had already led to 22 fixes in Firefox 148. Mozilla's assessment was candid and a little awed—"we've found no category or complexity of vulnerability that humans can find that this model can't"—and, importantly, hopeful. They called it good news for defenders, because a Firefox bug found by Mozilla is a bug fixed before an attacker sees it. Firefox 150's security advisory shows the scale: about forty individual CVEs plus three memory-safety rollups that bundle hundreds of bug reports, each rollup admitting that "with enough effort some of these could have been exploited to run arbitrary code."

But sit with the shape of that number. Two hundred and seventy-one holes, found in a rush, all of which then had to be fixed—understood, repaired without breaking anything else, reviewed, tested, and shipped—by the same finite team of human engineers. Finding was the fast part. Mozilla's own post is honest about the other half: so many findings at once "makes you stop to wonder whether it's even possible to keep up", and a team "may need to reprioritize everything else" to get through them. A model can hand you a thousand loose stones by morning. It cannot, on its own, cut and lay a thousand new ones into a live wall without the whole thing coming down.

You can see the strain from the other direction too, in a story that is almost the mirror image. The maintainer of curl, a tiny and beloved piece of software that sits inside more or less everything, shut down his project's bug bounty in January because the team was drowning—not in bugs, but in low-quality reports of bugs, many of them AI-generated, confident, plausible and completely made up. He had earlier described it as "death by a thousand slops": in the first half of 2025 roughly a fifth of submissions were AI-generated noise, while by early July only around five per cent had turned out to be genuine, and every single report still had to be read and disproved by a scarce human. The same technology that finds real 27-year-old bugs also generates infinite fake ones, and a human has to tell them apart. The bottleneck, again, is not the machine. It is the person.

The window was already closing before any of this

None of this pressure is new; AI has only jammed its foot on an accelerator that was already down. The security firm Mandiant has tracked, for years, the average time between a patch being released and someone exploiting the bug it fixes—the "time-to-exploit", which also counts bugs attacked before any patch existed—and the trend was frightening well before Mythos existed.

GPC:.1await

In Mandiant's analysis, the average time-to-exploit fell from 63 days across 2018 and 2019, to 44, to 32, and then to just 5 days in 2023.³ By 2023, on Mandiant's outlier-trimmed average, an exploited bug was under attack within a week of its patch, and seven in ten of the bugs Mandiant tracked that year were exploited as zero-days, before any patch existed at all. That was measured before Mythos-class tools existed. Now put the Glasswing capability on the attacker's side of that line—which Ireland's national cyber agency says has not happened yet—and the window does not merely shrink. For the worst cases it goes to nothing.

This is why the official reaction, from people not given to drama, has been so pointed. Ireland's national cyber agency, responding to Glasswing within a week, called it "a significant change in the way hardware and software vulnerabilities are identified and patched", noted with some relief that for now "the advantage is with cyber defenders" because the capability sits with the good guys, and told organisations in plain words to "review asset inventories, prioritise patching discipline, and assess exposure to unsupported components"—which is to say, go and look at the machine on your shelf. Rob T. Lee of SANS, a co-author of that joint industry briefing, put it less diplomatically: "the window between vulnerability discovery and weaponization has collapsed into hours".

So the finding is solved and the fixing is not. You cannot make your engineers a thousand times faster this quarter. What you can do is stop treating every loose stone as equally urgent, and get very good, very deliberately, at deciding which ones to run to. That is a patch policy, and it is the one thing in this whole story fully within your control.

Part 6: Priya Sets a Patch Policy That Fits in a Week

Meet Priya. Priya runs IT for a mid-sized logistics company in Devonport. (She is invented. Devonport is real, and its port is genuinely lovely.) She has about four hundred servers and endpoints, a small team, and a board that has just read a headline about AI finding "thousands of vulnerabilities" and would like to know, by Friday, that the company is "AI-secure". There is no such thing as AI-secure. There is a defensible patch policy, and Priya can build one this week.

Her instinct, and it is the right one, is to stop trying to patch everything and start triaging by the three questions from Part 2: how bad, is it being used, how likely to be used soon.

Monday: build the inventory, because you cannot patch what you cannot see

Priya's first move is not technical at all. She builds an honest list of every system the company runs, what software is on it, and—crucially—who owns it and whether it is still supported. This is the dull work the Irish agency was pointing at, and it is where the machine on the shelf finally gets written down. Every unsupported, unpatchable system is a loose stone that will never get a new one, so it needs a different plan: isolate it, wrap it, or replace it. You cannot defend an asset you have forgotten you own.

Tuesday: adopt a real, published patch clock

Priya does not invent her deadlines; she borrows a good set. Australia's own Essential Eight Maturity Model, from the Australian Signals Directorate, gives her plain, defensible time limits. At its first level, Maturity Level One, for internet-facing services, patches go on "within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist", and within two weeks otherwise. For the operating systems on ordinary workstations and internal servers, the window is one month.

Read those two limits again, because the design is clever. The 48-hour clock is not triggered by severity alone—it is triggered by severity or a working exploit existing. That second condition is the N-day window from Part 3, written into policy. The moment a crowbar exists for a stone in your wall, you have two days, whatever the CVSS score says. Everything slower is for the stones nobody is prising at yet.

Wednesday: wire in the "is anyone using this" signals

A published clock still needs a way to decide which bugs trip the fast timer. This is where Priya connects the instruments from Part 2. She subscribes her vulnerability scanner to CISA's KEV catalog: anything on that list has, by definition, been exploited in the wild, so it goes straight onto the 48-hour clock, no debate. For everything else, she uses EPSS as a filter, because she cannot patch all four hundred systems' worth of Medium findings at once and, as CISA notes, fewer than four per cent of CVEs have ever been publicly exploited.

Her rule of thumb, agreed with her team, is a small hierarchy: on the KEV list, patch now; not on KEV but high EPSS, patch this week; everything else, patch on the normal monthly cycle. She is explicit with the board that these thresholds are a statement of the company's risk appetite, not a law of nature—FIRST itself is careful to say it has "never published guidance around thresholds" because the right line depends on how much you can afford to do. Priya's line is set where her team's actual capacity meets her board's actual nerves.

Thursday: rehearse the emergency, and turn on what you can automate

The whole policy is worthless if the one genuinely urgent patch a year finds the team improvising. So Priya runs a fifteen-minute tabletop: a Critical, actively-exploited bug drops in software they run; who approves the emergency change, who deploys it, who tells the customers. She also does the least glamorous, most effective thing in the entire article: she turns on automatic updates everywhere she safely can. The single biggest lever on the N-day window is not a clever tool. It is closing the gap between "a patch exists" and "the patch is installed" without a human having to decide, every time, that today is finally the day.

Friday: tell the board the true thing

Priya does not tell the board the company is AI-secure. She shows them the inventory, the clock, and the KEV-and-EPSS triage, and says one sentence: "We can't fix every flaw, so we've made sure the ones being used against people get fixed first and fast." Her chair asks whether they should buy the AI bug-finder they read about. Priya says maybe, one day, as a way to find their own bugs first—but points out that a tool that hands them another thousand findings helps nobody until the finding-to-fixing bottleneck is solved, and that bottleneck is people and process, not models. He goes to make a cup of tea, which is the correct response to a patch policy that fits on one page.

What to Do This Week

You do not need a frontier model, a big budget or a security team the size of Mozilla's for any of this. The whole lifecycle collapses into a short, boring checklist that does most of the work.

1. Write down what you run. Build or refresh an inventory of systems, the software on each, who owns it, and whether it is still supported. The bug you cannot patch is almost always the asset you forgot you had.
2. Flag the unsupported. Any system that will never get another patch is a permanent loose stone. Isolate it, put it behind something that is patched, or plan its replacement now, not after the incident.
3. Adopt a published patch clock. Do not invent deadlines. Take the Essential Eight Maturity Level One timings: 48 hours for internet-facing services that are critical or have a working exploit, two weeks otherwise, one month for internal operating systems.
4. Subscribe to the KEV catalog. Treat anything on CISA's Known Exploited Vulnerabilities list as a fire, not a filing. It is the cleanest "patch this now" signal that exists, and it is free.
5. Use EPSS to triage the rest. You cannot patch everything at once, and you do not need to. Prioritise the small minority of bugs with a real probability of being used.
6. Separate severity from urgency, out loud. A Critical CVSS score in software nobody attacks can wait behind a Medium one that is on the KEV list. Say this to whoever wants everything patched yesterday.
7. Turn on automatic updates wherever you safely can. This is the highest-value, lowest-glamour action here. It closes your N-day window without a human deciding, every time, to reboot the thing on the shelf.
8. Rehearse the one emergency. Know, before it happens, who approves and deploys the out-of-cycle patch when a Critical, exploited bug lands in something you run.

Final Thoughts

Go back to the red badge on the machine on your shelf. Nothing about it has changed this year—it is the same small, ignorable nudge it always was. What has changed is everything on the other side of it: the loose stone it is quietly closing can now be found by a machine for a modest compute bill, and turned into a crowbar within days of the fix being public.

If there is one idea to keep from the whole life of a bug, it is this. A vulnerability is dangerous not in the abstract but in a window—the stretch of time between someone being able to attack it and you having closed the door. AI has taken the part of that window that used to protect you—the sheer difficulty of finding the flaw—and shrunk it toward nothing. The one part of the window still fully in your hands is the last one: how fast you install the fix. That is not a job for a frontier model. It is a job for an inventory, a clock and the discipline to run to the fires and walk to everything else.

So this week, before the next headline, do the unglamorous thing. Write down what you run, subscribe to the list of what is actually being exploited, and turn on the updates you have been putting off. The heroes in this story were never the ones who found the bug. They were the ones who quietly, boringly, had already installed the patch.

Now, if you'll excuse me, there is a small red badge on one of my own machines that I have been ignoring since Tuesday, and a fresh pot of tea says I deal with it before it deals with me.

Notes

1. The programme's reliance on a single government contract has itself been a minor drama; the funding wobbled in 2025 and had to be shored up. It is a slightly alarming thing to learn about a system the entire security industry leans on, but it is a story for another day. ↩

2. This is the same construct-validity problem that trips up analytics: make sure the number you are acting on measures the thing you actually care about. A severity score answers "how bad could this be?" and you keep treating it as if it answered "how worried should I be right now?". Two different questions, and the gap between them is where wasted effort and real breaches both live. ↩

3. Mandiant is honest about the messiness: the 5-day figure for 2023 strips out 15 statistical outliers. Leave them in and the average is 47 days. Either way, the direction is the same and the direction is down—and this is all measured before AI-written exploits entered the picture at scale. ↩