AI now finds zero-days on its own. Your problem is the 43 days that come after

The two numbers that decide what happens to you were published before Astra existed, and neither is about finding flaws. The first is minus seven days: mean time to exploit, per M-Trends 2026, is negative. The second is 43 days: the median an organisation takes to fully remediate a KEV-listed vulnerability, per this year's Verizon DBIR. Between the two there is not a single day that depends on how fast somebody finds the hole.

On 4 September OpenAI launched GPT-6 Astra and declared it the first model it deploys reaching the "Critical" cybersecurity capability level of its preparedness framework. It is a big story and it deserves the headlines it got. We run infrastructure and on-call rotations for clients, so the question we have been asked this week is not whether the model is impressive — it is — but what changes on Monday. The honest answer is uncomfortable: for most of the companies we know, nothing. And that is not the good news, it is the bad news.

What OpenAI said, with the figures and with the small print

The "Critical" threshold in their framework is defined by OpenAI itself along two routes, and this is the first: the ability to "identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention". The figures accompanying the announcement: on ExploitBench, Astra scores 100% against 78.5% for its predecessor GPT-5.6 Sol; on ExploitGym, a broader exploit-development benchmark, 42.4% against 30.3%, and using fewer output tokens. To rule out that it was reciting from memory, they tested it against flaws disclosed in the three months before launch — after its training cutoff — and along the way it found two previously unknown vulnerabilities, whose vendors are being notified.

Now the small print, which is our reading and we flag it as such. That 100% was measured, per the announcement itself, without production safeguards. The version a company can switch on in its workspace is restricted to secure code review and patching and refuses to generate proof-of-concept exploits. Those are two different configurations of the same model, and the headline number describes the one you do not get. This is not an accusation: OpenAI publishes it openly. It is that almost nobody reported it, and the gap between "the model can" and "the model you switch on can" is exactly what separates a news item from a purchasing decision. Access also ships off by default and an administrator has to enable it by hand.

The second detail. Relaxing those restrictions is planned for vetted defenders through a programme of their own, Daybreak. Which means: the offensive half reaches the world first as a demonstrated capability, and the defensive half arrives later and with a guest list. We do not know the criteria for getting on that list, and we are not going to pretend we do; we do note that a thirty-person company is rarely on lists like that. And one line that has been quoted little, from analyst Sanchit Vir Gogia: "Astra behaves better and watches worse". It behaves better and it is harder to watch: its chain of reasoning is less observable than the previous model's. A system that is more capable and simultaneously harder to audit is, in any engineering discipline, a combination that forces you to put controls around it rather than trust the system itself.

The two numbers that already decided your risk

M-Trends 2026, Mandiant's annual report, puts mean time to exploit at roughly minus seven days. The sign is what matters: it means that, on average, the flaw is being exploited a week before the patch exists. In 2018 that window was 63 days. It crossed zero in 2024. The series has not jumped: it has been falling in a straight line for years and it already passed below the line where patching, however fast, arrives first.

The other number moves the opposite way. Verizon's 2026 DBIR puts the median to fully remediate a KEV-listed vulnerability at 43 days, up from 32 the year before. It is not falling: it rises eleven days in twelve months. Putting the two side by side gives a window of about fifty days that opens before the vendor publishes anything. And here we should be precise, because this is the kind of arithmetic that gets repeated badly: one is a mean and the other a median, they come from different reports and different populations, so adding them is not statistics, it is a sketch. The sketch, though, does not depend on the sum: the two series are moving apart from each other, each measured independently and each in the direction that suits you least.

That is what Astra does not change. Not one of those fifty days is spent waiting for somebody to discover the flaw. They happen afterwards, on your side of the fence, between the fix existing and it reaching your machines.

The number that actually hurts: 26%

The same report leaves a figure that has been discussed far less and that strikes us as the worst of the three: of the CISA KEV vulnerabilities organisations actually have in their systems, only 26% get fully remediated, down from 38% the year before. Twelve points less in a single year.

Before drawing conclusions the counterweight belongs here, and it is in the same report: the median number of KEV vulnerabilities an organisation had to deal with rose from 11 to 16 in a year, nearly 50% more. Part of the drop from 38% to 26% is arithmetic, not neglect. But look closely, because the figure that comes out of it is the one that really disarms the volume excuse: the median company had sixteen. Sixteen in a whole year. And of those sixteen it closed four.

The KEV is not the list of every CVE in the world. It is a short list, filtered by somebody else, free and published, with a single entry condition: there must be evidence that this is being exploited right now. The expensive work — sifting, prioritising, deciding what matters — comes done. And the batches are single-digit: 3 entries on 11 August, 4 on the 18th, 6 on the 26th, 2 on the 31st and 7 on 2 September, to cite five publications we checked one by one. It is not a torrent: it is a trickle of a few a week, already prioritised.

If three out of four entries on the short list — the one somebody else filtered for you, the one containing only what is already being used against you — go unclosed, then "there are too many CVEs" was never the reason. And an engine that finds flaws faster does not change your risk: it changes your calendar. A queue you cannot clear when it is small does not get fixed because the world produces faster; it just gets longer. In the case of the ten CVEs in the same process we wrote about how we order that queue when the headline is not enough to decide.

Why 43 days is not laziness

The easy reading of those 43 days is that people do not patch out of neglect. Running other people's infrastructure since 2015, we have almost never seen that. What we have seen is that the number is the sum of five missing things, and none of the five is bought with willpower:

• You do not know where it runs. The advisory says "versions prior to X" and nobody in the room knows for certain how many machines there are or what version they are on. Inventory is not bureaucracy: it is the first of the 43 days.
• You have nowhere to test it. Without an environment resembling production, applying the patch is the test, and the test runs with the customers inside.
• You cannot undo it. If rollback means "restore last night's copy and lose the day", the decision stops being technical and becomes a bet.
• You cannot stop. The maintenance window exists on paper and in practice always falls in the week when it cannot happen.
• Nobody is awake. Advisories do not come out on Tuesdays at ten in the morning. The SonicWall one that occupied us in July entered the catalog with a three-day deadline that included the weekend.

And there is a sixth reason almost nobody says out loud because it sounds bad: the fear is rational. Patches break things. In August we described how a .NET update broke printing in production applications, and whoever lived through that learned a wrong but understandable lesson: wait. The answer to that fear is not courage, it is having somewhere to test. A team that can test does not need to be brave.

Nor are we going to sell you the idea that moving fast always works out. Last week we described how the build that fixed July's flaw is the newest one September declares vulnerable: whoever met the three-day deadline landed precisely on the build that returned to the catalog 49 days later. That is not an argument for waiting. It is an argument for not confusing "patched" with "safe", and for having the way back ready before you need it.

What actually moves the number

Nothing that brings the 43 days down is new or is a product. It is the same boring work as always: an inventory that maintains itself because the machines feed it and not a spreadsheet from two years ago; a test environment that resembles production closely enough for a failure to show up there; staged rollouts and one-click rollback; and telemetry that alerts on symptoms, not on "the service is up". It is exactly the same list that comes out every time we take apart a big incident, including the one where redundancy did not survive a procedure. Failure is inevitable; an outage is a design decision.

The fifth piece is missing and here we have to be honest because it touches our own pocket: you need somebody who can execute all of the above when the advisory lands on a Friday at nine in the evening, which is when it lands. We sell 24×7 on-call cover and it would be very easy to sell it on its own, as if hiring a night phone number lowered the median. It does not. An on-call rotation with no inventory, no test environment and no rollback is a person awake looking at an advisory they cannot apply without gambling. What lowers the number is having the four things done and somebody who can execute them outside your business hours. Neither half works alone, and anyone selling you only one is selling you half a solution. Serious IT maintenance consists, almost entirely, of having that list ready before it is needed.

When this is not about you

If your company is fifteen people with fifteen laptops, mail in the cloud, nothing published to the internet and no in-house application, this is not about you and building a patching programme will cost you more than it saves. Turn on automatic updates, run a supported operating system and go home. We say it knowing it sells us less, because the alternative is charging you for a fear that is not yours.

If on the other hand you have anything published — a remote access portal, an ERP, an application serving your customers — the order matters and it is not negotiable: inventory first. Without knowing what runs and on what version, everything else is theatre, expensive tools included. It is a month of boring work almost nobody wants to pay for and it is, by a distance, the best-spent euro on the list.

Before you quote us

We have not used Astra nor reproduced any of its figures. The 100%, the 42.4% and the two vulnerabilities found are data OpenAI publishes about itself, and the benchmark is theirs too. Nor are we saying attackers are using it: we have no evidence of that, the model is days old, and the deployed version refuses to generate proofs of concept. Neither do we know whether that discovery capability will translate into more real-world exploitation, or when. Anyone who says they know is predicting, and this is an infrastructure blog, not a futurology one.

And one about the date, because we ran into it and would rather say so: some outlets place the rollout to a limited set of organisations on 3 September and others the launch on the 4th, and the split is close to even — with the wrinkle that several of the mastheads giving the 4th are running the same syndicated article. We use the 4th because it is the date of the general availability announcement, and we write that down rather than choosing in silence.

What remains is the question you can answer today, without waiting for any model: how many days pass in your company between a fix existing and it being installed. If you do not have that number, that is this week's work. If you have it and it is high, you already know what you are competing against. Some of it will reach you before the patch exists, and against that it is detection that plays, not patching. But most of what will get in has been published for weeks with a fix available.

Note on sources

GPT-6 Astra's "Critical" cybersecurity capability level, its definition in OpenAI's preparedness framework, the ExploitBench scores (100% against 78.5% for GPT-5.6 Sol) and ExploitGym scores (42.4% against 30.3%), the test against flaws disclosed in the three months before launch, the two previously unknown vulnerabilities found and the restriction of the deployed version to secure code review and patching — refusing to generate proofs of concept — come from coverage of OpenAI's announcement in CSO Online, InfoWorld, Computerworld and The Hacker News, published between 4 and 8 September 2026; the official page openai.com/index/path-to-astra did not respond when we tried to read it. That the 100% was measured without production safeguards and that access ships off by default come from that same coverage; underlining that headline and product are different configurations is ours. The Daybreak programme for vetted defenders and the Sanchit Vir Gogia quote "Astra behaves better and watches worse" are from CSO Online. Mean time to exploit of roughly minus seven days, the 63 days in 2018 and the crossing of zero in 2024 are from Mandiant's M-Trends 2026. The 43-day median to fully remediate a KEV-listed vulnerability — up from 32 the previous year —, the 26% remediated — down from 38% — and the rise in the median number of KEV vulnerabilities per organisation from 11 to 16 are from Verizon's 2026 DBIR. Of M-Trends 2026 and the 2026 DBIR we have read the published coverage and summaries, not the full reports, and we cite them as such. The batch sizes from the KEV catalog (3 on 11 August, 4 on the 18th, 6 on the 26th, 2 on the 31st and 7 on 2 September 2026) come from the alerts CISA published on those dates, checked one by one; they are not meant as the total for the period, which includes further publications, but as the order of magnitude of each batch. The five reasons in the section on the 43 days are our own observation from running client infrastructure, not a study, and we give them as such.