The backlog that stopped shrinking

Every publicly known software flaw gets a reference number called a CVE — think of it as a licence plate for a specific bug in a specific product. For most of the 2010s the world produced around 18,000 to 20,000 of them a year. Enough to keep IT teams busy, few enough that a competent business could work through the ones that mattered.

The Forum of Incident Response and Security Teams (FIRST) now projects roughly 66,000 CVEs for 2026 — more than 46% above its own February forecast, revised sharply upward mid-year because the original figure was badly wrong. That's about 135 new disclosed flaws every day, up roughly 40% year on year.

The driver is AI. Frontier models have turned bug hunting from artisan work into something closer to industrial production. Mozilla's Q1 disclosures jumped 164%, attributed directly to AI-assisted tooling running against the Firefox engine. Chrome's disclosure volume is up more than five-fold. Microsoft's June 2026 Patch Tuesday shipped fixes for a record 206 distinct vulnerabilities in a single day — and Microsoft's own engineering leadership has warned that releases of that size are the new normal, not an anomaly. Across major vendors, June's high- and critical-severity disclosures ran at roughly three and a half times the previous monthly record.

Here’s the uncomfortable part for anyone who has ever been handed a vulnerability report and told to “get the number down”: the number is not going down. Not this year, not next year. The pipeline feeding it now runs at machine speed, and your remediation capacity does not.

So if the count is no longer a meaningful score, what is?

The patch is the map

The second half of this story is the part most businesses haven't priced in.

When a vendor ships a security update, they also publish — unavoidably — a precise description of what they fixed. Attackers exploit this through a technique called patch diffing: compare the old version of a file against the patched version, see exactly what changed, and work backwards to the bug the fix was written to close. The patch is a map to the weakness.

Historically that work was slow and highly skilled, which is precisely what bought defenders their breathing room. WannaCry — the ransomware that took down parts of the NHS — landed 59 days after Microsoft released the patch that would have stopped it. The public exploit for Citrix Bleed in 2023 took about two weeks to appear.

Those windows have collapsed. The same models finding bugs can now read a patch, identify the flaw and produce working attack code in hours. Palo Alto Networks' Unit 42 reports that opportunistic internet-wide scanning for newly disclosed flaws now begins within roughly 15 minutes of publication.

In 2018, Mandiant put the average gap between a vulnerability becoming public and being exploited at 63 days. By 2024 it had crossed zero. Mandiant's M-Trends 2026 now estimates it at negative seven days — meaning that on average, exploitation is already underway before the flaw is disclosed and before a fix exists. CrowdStrike found 42% of exploited vulnerabilities were attacked before public disclosure.

Nine hours and forty-one minutes

On 8 April 2026, the maintainers of Marimo — an open-source Python notebook used widely in data and AI workflows — published an advisory for a serious flaw allowing remote code execution without any login. There was no public proof-of-concept. No exploit code circulating. Just the advisory text describing the problem.

Nine hours and forty-one minutes later, security firm Sysdig observed the first real-world exploitation. Someone had read the advisory, built a working exploit from it, opened a shell on a live system and stolen cloud credentials — the theft itself taking about three minutes.

Now ask the question that matters: in those nine hours, what would your organisation have done? For most Australian businesses, the honest answer is nothing. The advisory hadn't been read. The asset hadn't been identified. The change request hadn't been raised.

The gap is the whole contest

Which brings us to the number that belongs on your board report.

Verizon's 2026 Data Breach Investigations Report, drawing on more than 13,000 organisations, found the median time to fix a known-exploited vulnerability — not a theoretical one, a flaw attackers are actively using — is now 43 days, up from 32 the year before. The share ever fully remediated fell from 38% to 26%. Even top performers close only 30–40% within the first week.

Offence now runs in hours. Defence runs in weeks, and is getting slower. Breaches happen in the space between.

This is why the old score no longer works. “How many vulnerabilities do we have?” is a question with an infinitely growing answer. “How long between a patch existing and us applying it?” is a question with a finite answer, a clear target, and a direct relationship to whether you get breached. That number — call it patch latency — is the real security score now.

Not every CVE is an emergency

If you've read this far and feel a rising sense of panic, here is the necessary corrective: you do not have to patch 66,000 things.

Jerry Gamblin, co-author of the FIRST forecast, uses a weather analogy that deserves wider circulation. Total disclosure volume is the rainfall. The rain isn't stopping. But the water that actually threatens to flood the house is a much smaller quantity — the flaws attackers are genuinely using, or are most likely to use soon. Filter the flood down to that set, and the urgent workload has stayed remarkably flat, even as the headline number exploded.

Two free public tools do that filtering. CISA's Known Exploited Vulnerabilities (KEV) catalogue lists flaws confirmed to be under active attack. The Exploit Prediction Scoring System (EPSS) estimates the probability a given flaw will be exploited in the next 30 days. Together they turn an unmanageable list into a short one.

The organisations drowning right now are largely those treating every new CVE as equally urgent — burning engineering capacity on theoretical bugs while the genuinely dangerous ones sit open for 43 days.

Your delay is almost never technical

Here's what we consistently find when we audit patch latency: the hold-up is rarely the patch itself. Applying an update is usually a matter of minutes. The weeks are consumed by everything around it — nobody noticed the advisory, nobody knew the affected system existed, the change board meets on Thursdays, the maintenance window is the last Sunday of the month, and the vendor who manages that server hasn't replied.

That's an organisational problem wearing a technical costume. And organisational problems can be fixed without buying anything.

Australia’s regulators already recognise the direction of travel. The ASD Essential Eight requires critical vulnerabilities, and those with known exploits, to be patched or mitigated within 48 hours — with a two-week ceiling for internet-facing applications and software handling untrusted content. In the US, CISA has reportedly weighed cutting its standard remediation deadline from two weeks to three days. If your patching runs on a monthly cadence, you are already outside the standard your insurer, your enterprise customers and your auditors are moving toward.

What fast actually looks like

Six things separate organisations that survive this from those that don't:

1. Know what you own. You cannot patch an asset you've forgotten about. The forgotten VPN appliance, the old marketing site, the test server someone spun up in 2022 — these are where breaches start. A live, accurate inventory is the foundation everything else sits on.

1. Monitor continuously, not periodically. Quarterly scanning is meaningless against a ten-hour exploit window. You need to know about relevant advisories the day they land, not at the next review.

2. Tier by exposure, not by severity score. An internet-facing system with a moderate flaw is more urgent than an isolated internal one with a critical flaw. Attackers scan what they can reach.

3. Pre-authorise emergency patching. Decide now, in writing, who can bypass the normal change process when something is on the KEV list, and what testing is required. Making that decision during an incident costs days you don't have.

4. Automate the routine 80%. Reserve human judgement for the systems that genuinely can't take an unattended update. Everything else should patch itself.

5. Assume some window stays open. When exploitation routinely precedes the patch, patching alone cannot be your only control. Network segmentation, tested backups, least-privilege access and genuine detection capability are what limit the damage when the fix arrives too late.

Patching is a privacy issue

It's worth remembering what's at stake. Under Australia's Notifiable Data Breaches scheme, an unpatched edge device that leaks customer records isn't just an IT incident — it's a reportable breach, a regulatory conversation, and a permanent dent in your customers' trust. The technical failure lasts hours. The privacy consequences last years.

The businesses that come through the AI era intact won't be the ones with the longest tool list or the cleanest vulnerability dashboard. They'll be the ones who can honestly answer one question: when something dangerous drops, how long until it's closed?

If you don't know your number, that's the first thing worth finding out.

 

Xiph Cyber helps Australian organisations turn patch speed into a measurable, defensible discipline — through continuous monitoring and managed security services, cyber risk audits that test real-world performance rather than policy documents, Essential Eight maturity assessments, and vCISO support for businesses without a full-time security leader. Get in touch and you'll speak to a real person within 24 hours.