The CVE Wave Is Coming. Most Organisations Are Not Prepared.

Organisations remain unprepared because traditional patch management cycles, often weekly or monthly, are structurally incompatible with the modern exploit timeline, where working attacks now emerge within hours of disclosure. Closing this gap requires continuous vulnerability monitoring, automated prioritisation based on real-world exploitability, and the organisational authority to patch critical systems immediately, outside scheduled windows.

Published on andrewbaker.ninja

It is 09:47 on a Tuesday morning. A researcher publishes a new CVE (Common Vulnerabilities and Exposures) for a widely deployed authentication library. The advisory goes live. Within minutes, an AI system on the other side of the world ingests the patch, reverse engineers it, identifies the memory corruption flaw the patch was silently addressing, and generates a working exploit. By 10:15, automated scanners are sweeping the internet for exposed instances. By 11:00, your organisation’s externally visible service running the vulnerable version has been identified, fingerprinted, and added to a target list. By afternoon, the credential harvested from a session cookie on that service is being tested against your VPN. Your patch cycle runs on Tuesdays. Next Tuesday.

This is not a hypothetical. It is a description of how exploitation works in 2025, and the timeline is compressing further.

Something important changed in 2024 and most security teams have not yet absorbed it.

In 2024, the number of CVEs published in a single year crossed 40,000. In 2025, it hit 48,000, pushing the all time total past 308,000 recorded vulnerabilities. Since 2016, annual CVE volume has risen by 520%. This is not a trend that is flattening. The curve is accelerating, and the question every security leader must now answer is not whether the next wave will arrive, but whether their detection and response architecture was designed for the world that existed before it.

Against that backdrop, the emergence of AI native security platforms like Mythos is not an incremental improvement. It is a category shift, and the timing could not be more consequential.

1. The Zero Day Clock Has Already Collapsed

There is a live dashboard called the Zero Day Clock, built by Sergej Epp, CISO of Sysdig, that tracks what researchers are calling the collapse of time to exploit (TTE). It synthesises data across more than 83,000 CVE exploit pairs drawn from CISA KEV, ExploitDB, Metasploit, VulnCheck, and other authoritative sources. The numbers it shows are not projections. They are measurements of something that has already happened.

In 2018, the median time between a vulnerability being disclosed and the first confirmed exploitation in the wild was 771 days. Organisations had more than two years to patch. By 2021 that window had compressed to 84 days, a ninefold compression in three years. By 2023 it was 6 days. By 2024 it was 4 hours.

In 2025, the majority of exploited vulnerabilities were weaponised before they were even publicly disclosed. The window did not just close. It inverted.

The mechanism driving this inversion is AI assisted reverse engineering. When a software vendor releases a security patch, AI can now analyse the patch, infer the underlying vulnerability it addresses, and generate a working weaponised exploit in minutes. The act of patching now accelerates the exploitation of the very flaw being fixed. Bruce Schneier, Heather Adkins of Google, and others noted in late 2025 that the attackers’ AI singularity has arrived. The defenders’ has not yet begun.

The reason offense outpaces defence in this dynamic is structural, not incidental. Sergej Epp has described it as verification asymmetry. When an attacker’s AI generates an exploit attempt, feedback is immediate and binary: the exploit either worked or it did not. The system learns at machine speed, iterating against a live target with no ambiguity in the result. Defence has no equivalent feedback loop. A defensive AI model cannot know whether a threat was real, whether a detection was accurate, or whether a patch actually closed the exposure without extensive validation, testing, and human review. The attacker’s learning cycle runs in seconds. The defender’s runs in weeks. This is not a gap that more analysts or faster patching closes. It is a structural asymmetry that only AI native defence architecture, operating at the same speed as the attack, has any prospect of narrowing.

The implications for conventional patch based security are severe. Organisations following best practice patch management cycles of 14 to 30 days are now operating on a cadence that was designed for a threat landscape that no longer exists. Researchers project that time to exploit will compress to minutes by 2028. At that point, patching as a primary defence strategy becomes structurally incoherent.

2. The Volume Problem Will Kill Legacy Attack Surfaces

48,000 CVEs in a single year is a triage problem that no human security team can absorb using traditional workflows. But the more important point is about the shape of vulnerability, not just the count.

Legacy enterprise software carries enormous attack surface by nature of what it is. A Windows based enterprise system with a gigabyte of runtime dependencies, dozens of bundled services, and a 40 minute restart cycle is not just a patching inconvenience. It is a structural liability. Microsoft’s March 2026 Patch Tuesday addressed 78 vulnerabilities in a single release cycle, including at least one that was already under active exploitation when the patch dropped. That is the new normal.

The question worth asking is whether Microsoft, and vendors in a similar position, can continue absorbing the compounding weight of an enormous installed surface across decades of backwards compatible code. At some point the attack surface does not shrink through patching; it just redistributes. A new operating system designed from clean principles is not a thought experiment at this stage. It is a structural necessity for vendors whose legacy codebase has become the primary mechanism through which attackers enter enterprise environments at scale.

For organisations that have not yet migrated critical workloads to managed or minimal surface infrastructure, this is the moment to treat that migration as a security imperative rather than a cost exercise.

3. The Supply Chain Is the Attack Surface Most Organisations Cannot See

The hook scenario at the opening of this post described a CVE in a widely deployed authentication library. That detail was not incidental. The dominant real world expression of the CVE wave is not attackers finding vulnerabilities in code your organisation wrote. It is attackers finding vulnerabilities in code your organisation is running without knowing it is there.

Log4Shell in late 2021 was the canonical illustration. A critical vulnerability in a Java logging library that had been quietly embedded in thousands of enterprise products, many of which had no idea they were running it. Organisations that believed they had no Java exposure discovered it was inside their network monitoring tools, their ticketing systems, their identity platforms. The XZ Utils backdoor in 2024 demonstrated something more alarming: a sophisticated actor patiently contributing to an open source project for two years with the specific intention of introducing a supply chain compromise. These are not edge cases. They are the new centre of gravity for enterprise risk.

Most organisations have reasonable visibility into their first party code. Very few have reliable inventory of their transitive dependencies, the libraries their libraries depend on, the containers their vendors ship, the build tooling their CI pipelines pull at runtime. That invisible layer is now the primary terrain where CVEs land with real organisational impact.

The implication for attack surface visibility is significant. Knowing your own exposed services is necessary but not sufficient. You need to know what is running inside those services, what it depends on, and whether any of those dependencies carry known vulnerabilities that are currently being actively exploited. That is not a task that scales manually at 48,000 CVEs per year. It requires automated dependency graph analysis, continuous reconciliation against vulnerability feeds, and the ability to distinguish a CVE in a library version you are actually shipping from one in a version you retired two years ago.

4. Managed Surfaces Without Attack Surface Are Already Here

The most structurally sound response to CVE volume is to eliminate the attack surface, not to patch it faster. Cloud managed services like Amazon RDS, Amazon EKS, and their equivalents across other providers have already demonstrated what this looks like in practice.

When you use RDS, you do not run a database server. You consume a database service. The underlying operating system, the network stack, the patching cycle for the database engine itself, all of that is absorbed and managed by the provider. The attack surface visible to an adversary attempting to reach your data is dramatically smaller than it would be if you were running PostgreSQL on a self managed EC2 instance with full OS exposure. The same logic applies to EKS for container orchestration. The control plane is not your problem. Its vulnerability surface is not your attack surface.

This principle scales. The further you move from managing the substrate, the less attack surface you expose. It is not magic. It requires tradeoffs in flexibility and control. But from a pure vulnerability exposure perspective, managed services are structurally superior to self managed infrastructure in a world where CVE volume is compounding at 38% year over year.

The honest counterargument is that managed surfaces introduce their own risk profile. You are trusting the provider’s patching cadence, accepting their shared responsibility boundaries, and in some configurations absorbing multitenant risk that does not exist in dedicated infrastructure. Provider level incidents, while rare, tend to be large when they occur. These are real tradeoffs, not theoretical ones, and any organisation moving workloads to managed surfaces needs to understand precisely where the provider’s responsibility ends and theirs begins. The argument here is not that managed surfaces are risk free. It is that their risk profile is structurally more manageable than running a large inventory of self managed servers in a world of 48,000 CVEs per year.

The organisations most at risk right now are those still running large inventories of self managed servers, with full operating system exposure, on patching cycles that assume the old time to exploit windows still apply.

5. The Micro OS Advantage Is Real

At the far end of the attack surface reduction spectrum sits unikernel architecture. A unikernel is a specialised image compiled specifically for a single application, containing only the libraries that application actually needs to run. No shell. No unneeded system calls. No background services. No generalised OS surface that an attacker can pivot through.

A production Unikraft image, one of the leading unikernel frameworks, contains no shell, no unneeded system services, and no dead code. These images can be as small as 2MB. A comparable messaging application built on Linux might use 20 to 40 times more code simply because Linux is a generalised operating system that must accommodate applications it has never seen. Every line of code that does not need to be there is a line of code that cannot be exploited.

The Linux kernel as of 2025 contains over 40 million lines of code. A microkernel like KasperskyOS is built on approximately 100,000 lines, roughly 400 times smaller. The attack surface difference is not linear. It is qualitative. You cannot exploit system calls that do not exist.

Unikernels boot in milliseconds, consume minimal memory, provide strong isolation at the hypervisor level, and eliminate entire classes of lateral movement that depend on the generalist OS environment to be present. For cloud native workloads, high performance API gateways, and security sensitive microservices, this architecture is not experimental. It is production viable and growing in adoption.

The tradeoffs are real and worth naming. Unikernels are harder to build, harder to debug, and require specialised tooling that most engineering teams do not currently have. Porting existing applications is nontrivial. Standard debugging tools do not work against a running unikernel the way they work against a Linux process. The ecosystem, while maturing, does not yet have the breadth of support that containerised Linux workloads have accumulated over a decade of production use. These are adoption barriers, not architectural flaws, and for greenfield cloud native services the tradeoff calculus is increasingly favourable. For legacy workloads, managed services are the more practical near term path.

The CVE wave will continue. Organisations running minimal OS images will ride it more easily than those still managing gigabytes of enterprise substrate per workload.

6. Detection Has to Assume the Attacker Is Already Inside

The Cloud Security Alliance and the broader security research community have been moving toward a consistent conclusion: perimeter defence alone is not sufficient when exploitation windows collapse to hours. The question is no longer only whether the attacker will get in. It is whether you will know when they do, and how quickly you can act.

This is where deception technology has moved from academic curiosity to operational necessity. The core insight is elegant and sobering: a legitimate user has no reason to touch a honeypot. The moment something in your environment interacts with a decoy credential, a fake Active Directory account, a synthetic API key left in a plausible location, or a honeypot service that should never receive traffic, you have a high confidence detection with near zero false positive rate.

Modern deception platforms have moved well beyond static honeypots. The approach now involves distributing lightweight decoy assets across endpoints, cloud workloads, Active Directory, and network infrastructure, making traps indistinguishable from legitimate assets. An attacker who has compromised a credential and is moving laterally through your environment will interact with these decoys before reaching the actual target. That interaction is your signal.

The practical example matters here. A credential embedded in a cookie, a plausible looking API key committed in a config file, a fake service account with realistic naming convention, these are breadcrumbs that lead attackers into instrumented space. When they take the bait, they announce themselves precisely at the point where traditional signature based detection fails. Deception based detection decreases attacker dwell time from months to hours, and because decoy interactions are definitionally anomalous, they generate almost no alert fatigue.

Knowing that someone is in your environment, and knowing it within minutes rather than months, is the signal that transforms an incident from a catastrophic breach into a contained event.

7. Your Public Attack Surface Is Visible to Attackers Before It Is Visible to You

There is a quieter problem that sits upstream of detection: most organisations do not have a complete, real time picture of their own public attack surface. Attackers scan the entire internet continuously. They know what services you are running, what ports you are exposing, and what versions of what software are visible from outside your perimeter. In many cases, they know this before your own security teams do.

This is not hypothetical. Attack infrastructure today scans the entire internet at machine speed as a matter of routine. When a new CVE is published, every exposed instance of the vulnerable software is identified within hours. Given that time to exploit is now measured in hours to minutes, the gap between a vulnerability being known to an attacker and being exploited against your specific exposed service is razor thin.

The minimum viable response to this is continuous external attack surface monitoring: knowing what you are exposing, knowing when something new appears, and treating every unanticipated exposure as a live incident rather than a configuration drift to be cleaned up in the next sprint. Mythos’s positioning around attack surface visibility is not an adjacent feature to its AI capabilities. It is the precondition for everything else. You cannot defend what you cannot see.

8. Where Mythos Fits and Why the 20x Projection Is Credible

Mythos is an AI native security platform built around the premise that the three problems described above, CVE volume, attack surface visibility, and post breach detection, cannot be solved independently. It combines continuous external attack surface monitoring with AI driven CVE triage and deception aware detection, treating them as a single integrated loop rather than three separate tools that happen to share a dashboard. When a new CVE is published, Mythos maps it against your actual running environment, including your dependency graph, not just your first party services, and surfaces only the subset that represents genuine, immediate risk given your specific configuration. That distinction matters enormously at 48,000 CVEs per year.

A clarification worth making here: the argument that patching is insufficient is not an argument that patching is worthless. The vast majority of CVEs published in any given year are never weaponised against real targets. Patching is still the right response to that long tail, and risk based prioritisation, knowing which CVEs to treat as emergencies versus which can follow normal cycles, remains one of the highest value activities a security team can perform. What AI native tooling changes is the ability to make that prioritisation accurately and continuously, rather than relying on vendor severity scores that do not account for your specific exposure or the current state of active exploitation in the wild. Mythos’s triage layer is not a replacement for patching. It is the mechanism that tells you which patch matters today.

The claim that Mythos’s impact will expand by at least 20x is not a marketing number. It is a reflection of the underlying dynamics. CVE volume will not slow. The Zero Day Clock will not reverse. The attack surface of organisations running legacy substrate will not shrink on its own. The gap between what security teams can manually process and what the threat environment demands has become structurally unbridgeable without AI native tooling.

Where AI genuinely transforms security operations is in the triage layer: sorting 48,000 CVEs per year for relevance to your specific environment, correlating deception telemetry with external threat feeds, mapping your public attack surface in real time, and identifying the narrow slice of vulnerabilities that represent genuine, immediate risk versus the overwhelming majority that are theoretically interesting but operationally irrelevant to your configuration. That is not a task where adding more analysts helps. It is a task designed for AI.

8.1. Firefox and the Patch Treadmill: Evidence From the Wild

The Firefox release cadence in 2026 illustrates the argument precisely. Mozilla released Firefox 150 on April 21, 2026, patching 41 security vulnerabilities, including 9 rated High severity, spanning critical browser components including DOM, WebRTC, JavaScript engine, web codecs, and graphics. That single release was not an isolated event. Since the start of 2026, Mozilla has issued security advisories at a rate of roughly one every two weeks, with Firefox moving from version 147 to 150.0.3 inside five months, each release carrying its own payload of memory safety bugs, sandbox escapes, and authentication bypass vulnerabilities. thecybrdefMozilla

What makes the Firefox example more than a volume statistic is what it reveals about the AI side of the equation. Anthropic’s Mythos AI model discovered 271 vulnerabilities in Firefox, and Mozilla noted that Mythos demonstrated the ability to chain medium and low severity issues into a critical exploit, and to identify logic based issues that traditional tools would not detect. That capability cuts both ways. The same AI assisted reasoning that finds 271 bugs on the defensive side is available to threat actors on the offensive side, which is precisely the verification asymmetry the post describes. SecurityWeek

The pattern is already visible in the point release cadence. Firefox 150.0.2 was issued as an emergency patch, the second emergency update within weeks of the major 150 release, driven by memory corruption bugs where Mozilla acknowledged that with sufficient effort the flaws could be exploited to run arbitrary code. That is a browser vendor operating in exactly the reactive posture the post argues is now structurally insufficient: patches shipped, exploits potentially already in development before the advisory is public. Carthage Electronics

9. The Strategic Posture for the Next 24 Months

The practical recommendations that follow from this analysis are not a checklist. They are a layered architecture where each element compensates for the limits of the others, and the order matters.

Start with visibility. You cannot prioritise what you cannot see, and you cannot defend what you do not know you are running. Continuous external attack surface monitoring, including dependency graph visibility for supply chain exposure, is the foundation everything else rests on. Without it, CVE triage is guesswork and deception deployment is incomplete.

Move workloads to managed surfaces where the attack surface is absorbed by the provider and patching cycles are invisible to your team. RDS, EKS, and equivalent services exist precisely to eliminate the substrate layer of exposure. For new cloud native workloads, evaluate unikernel architecture where the application footprint justifies the investment in specialised build tooling. The footprint reduction is measurable and the security properties for single purpose services are structurally superior.

Deploy deception infrastructure as an operational detection layer, not a research exercise. The value of deception is that it catches precisely the attacker behaviour that bypasses every other control: the lateral movement of a legitimate looking identity, the credential stuffing that signature based tools cannot distinguish from normal login traffic, the quiet reconnaissance that precedes a targeted attack. Distributed decoys with SOC integrations close the detection gap that managed surfaces and micro OS images leave open, because even a minimal attack surface can be breached, and when it is, you need to know within minutes.

Apply AI native triage to CVE prioritisation continuously. Not quarterly. Not at patch cycle. Continuously, because the exploitation landscape against your specific exposed services changes every time a new CVE is published or a new exploit is confirmed in the wild.

These four layers are not independent investments. They are a system. Visibility feeds triage. Surface reduction shrinks the triage problem. Deception catches what surface reduction does not prevent. AI triage ensures the human response capacity that remains is directed at what actually matters. The organisations that will manage the CVE wave successfully are those that stopped trying to patch their way to safety and started designing environments where the attack surface is small enough, and the detection layer is sensitive enough, that the asymmetry of the Zero Day Clock stops being an existential problem and becomes a manageable one.

10. The Write-Off Question: When Patching Costs More Than Starting Again

There is a question that security leaders are beginning to ask in private but not yet in public, because it carries consequences that no board wants to confront: what happens when the cost of remediating the security debt inside a legacy operating system or enterprise database exceeds the value the system delivers? Not the replacement cost, which is enormous and well understood, but the ongoing cost of keeping an already vulnerable system from becoming a liability that destroys the organisation running it.

This is not a theoretical question. Veracode’s 2026 State of Software Security report found that 82% of organisations now carry what it defines as security debt, up from 74% a year earlier, and 60% are dealing with severe exploitable flaws that have remained unresolved for more than a year, up 20% year on year.  That is not a patching backlog. That is a structural condition. Detection has improved significantly. Remediation capacity has not kept pace, and in legacy environments it cannot, because the remediation path often requires changes to subsystems that have not been touched in decades and cannot absorb disturbance without breaking the business processes running on top of them.

The Windows installed base makes this visible at scale. As of December 2025, Windows 11 held only 50.68% of the Windows desktop market, meaning that nearly two months after Windows 10 became end of life, roughly half of all Windows desktop computers had not been upgraded to a supported operating system.  Those machines are not running unsupported software because their owners are unaware of the risk. Many are running it because migration is not straightforward: a Windows Server 2008 environment scanned in 2026 returned 247 vulnerabilities, 89 of them rated critical or high severity, and systems still vulnerable to Log4Shell in 2026 are almost exclusively legacy environments where patching would require extensive testing or application rewrites.  The patch does not exist, or cannot be applied without breaking the application layer, which itself cannot be replaced because the vendor is gone or the integration surface is too deeply embedded.

Enterprise databases are compounding this. Oracle systems across databases, hardware, and applications are hitting end of life between 2026 and 2032, and for organisations in that position, the cost of staying on extended support is running at $300,000 to $500,000 per system per year, with no security patch coverage once sustaining support is the only remaining option.  Sustaining support provides access to pre-existing fixes only. New CVEs against a system on sustaining support are permanently unpatched. The organisation is paying for the illusion of a support relationship while actually operating with a growing inventory of known, unaddressed vulnerabilities. Compliance standards have shifted to match this reality: the 2025 update to SOC 2 and ISO 27001 introduced architectural obsolescence as a reportable finding, and auditors now quantify the risk of running a database version that exited extended support before 2022. 

The write-off scenario is not about a system becoming too expensive to run. It is about a system becoming too dangerous to run and simultaneously too expensive and too deeply entangled to replace on any reasonable timeline. Ransomware groups targeting industrial and enterprise organisations surged 49% year on year in 2025, with attackers routinely exploiting unpatched legacy software as an initial access vector before pivoting deeper into networks, and nearly 29% of known exploited vulnerabilities in 2025 were weaponised on or before the day their CVE was published.  That combination is lethal for organisations whose legacy stack cannot absorb emergency patches because the systems restart in 40 minutes and the patch cycle requires regression testing that takes three weeks.

Under PCI DSS 4.0.1, Requirement 12.3.4 states that all hardware and software in the cardholder data environment must be vendor-supported, and QSA commentary is unambiguous: an end of life technology in scope is an automatic finding.  For a financial institution running a legacy database in a payment processing context, that finding is not a compliance risk in the abstract. It is a potential licence to operate question. When regulators reach the point of issuing mandatory retirement notices rather than findings, organisations that have not already migrated will face a choice between an emergency transformation at cost and pace that almost guarantees failure, or an orderly wind down of the product line or business unit the system supports.

The ecosystem collapse argument follows from that logic. When a core platform is declared unsupportable, every system that depends on it for authentication, data storage, transaction processing, or reporting faces the same verdict simultaneously. The integration graph of a large enterprise is not a set of independent systems. It is a dependency tree, and the legacy operating system or database is often the root. When the root is written off, the entire tree comes down together. Not gradually, and not on a schedule the organisation controls. It comes down on the schedule determined by the next critical CVE that the vendor will not patch, or the next regulatory deadline that cannot be extended, or the next insurer who will not renew coverage for a platform they have already flagged. The organisations that will navigate this are those that began the migration before it became an emergency. For those that did not, the write-off is not a decision they will get to make. It will be made for them.

References

Andrew Baker is Group CIO at Capitec Bank. The views expressed here are his own. This post was written in a personal capacity.