I first heard the word a month ago. Anton Chuvakin used it in a post and asked the community for feedback on the definition. He wrote it like this.
Anton’s Vulnpocalypse equals a rapid step change in the number of software vulnerabilities, including zero days, exploitation based on them, and the resulting damage.
I read it twice. Something in me recognized it before I finished the second pass. Not surprise. Recognition. This was a thing I already knew was coming, sooner or later, and now it finally had a name. Something clicked, and something else did not.
The click was obvious. We are living through a step change. Anyone close to a vulnerability feed, a threat intelligence desk, or a patch management queue already feels it in their bones. The volume is different this year. Not a little different. Structurally different.
What gave me pause came from thirty years of watching this problem up close. I have never felt the number of vulnerabilities was the real issue. Counting vulnerabilities feels a little like counting rainfall and calling it a flood, when the rain itself was never the danger. It only becomes one where the water rising behind the dam finds a crack nobody sealed in time.
In cybersecurity, that crack in the dam has a name. It is the distance between a patch existing and a patch being applied.
Where I Pushed the Definition
Anton’s definition captures the volume. It captures the exploitation. What I feel is missing is the part that actually turns volume into damage. A vulnerability with no exploit is a crack in the dam below a waterline the reservoir has not reached yet. A vulnerability with an exploit and no friction to remediation is a crack sealed before the rising water reaches it. Damage only compounds when the water rises faster than we can find and seal the crack.
So I sat with the definition for a while, trying to see if it could also work for a board, not just for a technical audience.
Vulnpocalypse equals a rapid step change in the volume of software vulnerabilities, including zero days, and their exploitation, compounded by structural friction in patching and remediation, producing damage at a scale defenders cannot absorb.
That last clause is the whole argument. Damage at a scale defenders cannot absorb. Not a scale we find inconvenient. Not a scale that requires an extra sprint. A scale where the math of remediation capacity no longer closes, no matter how good your team is.
I have written before about the gap between a patch existing in a source tree and a patch existing in production. That gap used to be measured in weeks or months. It was already a problem before anyone coined a name for it. What changed is not the existence of the gap. What changed is what now pours into it.
A Flaw That Was Never Added
There is something almost strange about how a vulnerability comes into existence, and it is worth sitting with before we get to what is accelerating it.
Take a server. Fully patched, fully current, nothing wrong with it. Power it down. Put it in a locked room. Walk away for three months.
Come back, plug it in, boot it up. The server has not changed. Not one file. Not one line of code. And yet it now carries a handful of critical vulnerabilities that were not there the day you shut the door.
Nothing was installed on that machine. Something was discovered about it. That is the part that should unsettle every executive reading a vulnerability report. We talk about vulnerabilities as if they are added to a system, like rust forming on a hinge. They are not. They were already there. Somebody simply found them.
Which means the number we quote in every board deck, every risk report, every dashboard, is not a measure of how insecure our software became. It is a measure of how much other people already know about software that never changed at all.
And that raises an uncomfortable question nobody likes to sit with for long. Who found it first, and did they tell us.
Thousands of people spend their careers studying the code the rest of us run. Some work for the vendor. Some work for a bounty program. Some work for a government with no plan to ever file a disclosure. Some work for buyers who pay far better than any bug bounty ever will, and who have no interest in a patch existing at all.
The vulnerabilities we argue over, the ones with a CVE number and a patch Tuesday, are only the ones somebody decided we were allowed to know about. Every disclosed vulnerability is a choice, not just a discovery. What never gets disclosed, what sits quietly in someone else’s inventory waiting for the right moment, is the part of this problem no dashboard will ever show you.
Some of what they find never becomes a CVE at all. It becomes a capability. A nation state does not report a flaw it plans to use. It keeps it the way a military keeps a weapon in storage, not to fix it, but to reach for it exactly once, against exactly the target that matters, at exactly the moment it matters most. Criminal groups behave the same way with less patience and more hunger, because a flaw nobody else knows about is worth more on their market than almost anything else they could steal. These are not undiscovered vulnerabilities. They are cyber weapons built from silence. The flaw existed the whole time. Somebody simply chose to use it rather than report it.
This is why the Vulnpocalypse cannot be measured only by what we can count. The count is the visible tip. The rest is exactly where it has always been, out of sight, and increasingly out of reach.
The Trigger Nobody Priced In
Something is throwing fuel into that gap right now, and it is not subtle. The new wave of AI frontier models writes code faster than any team of humans ever could. It also reads code faster, finds patterns in code faster, and increasingly finds flaws in code faster. The same capability that helps a developer ship a feature in an afternoon helps an attacker discover a flaw in that feature in the same afternoon.
We have seen acceleration before. Open source exploded the number of dependencies a decade ago. Cloud migration multiplied the attack surface a few years later. Each time, the volume of exposure grew, and each time, the industry adapted, slowly, painfully, but it adapted.
This is different, and I want to be precise about why. Every previous acceleration hit one side of the equation. More code meant more vulnerabilities. More cloud meant more misconfigurations. But the defender side of the equation stayed roughly human paced. Analysts still triaged at analyst speed. Patches still got tested at engineering speed.
AI frontier models are accelerating both sides of the equation at once. Discovery is faster. Exploit generation is faster. And on the defender side, the tooling that promises to catch up is still mostly aspirational, still mostly a pilot project, still mostly a slide in next year’s budget request. We are not facing a bigger version of an old problem. We are facing the first vulnerability crisis where the attacker’s tooling matured faster than the defender’s.
I have watched vulnerability timelines for decades. The pattern was always the same. A flaw gets discovered. A patch gets written. Attackers wait for a proof of concept to appear before most of them act, because writing a working exploit used to take real skill. That waiting period was, in its own broken way, a kind of mercy. It gave defenders a window.
AI frontier models are closing that window. Not eliminating it everywhere, not yet, but compressing it in a way the industry has never had to plan for.
And remember, this acceleration is not only happening in public. Every researcher who once spent months finding a flaw by hand can now find several in an afternoon, whether they intend to report it or keep it. The private inventory grows exactly as fast as the public one, only we never see it grow.
The Number I Did Not Expect to See This Soon
Everything I have written so far was argument. Here is the evidence, and I did not expect to be holding it this early.
Microsoft ships patches every second Tuesday of the month, and it has done so for twenty years without interruption. That cadence gives us the cleanest twenty year dataset in the industry, because the process never changed. Only the volume flowing through it did
For most of those twenty years, the climb was steady but unremarkable. The count opened at 255 CVEs in 2007. It moved through the 300s, the 500s, the 800s, year by year, the kind of growth a security program can plan around. In 2020 it reached 1,250, the highest annual total Microsoft had ever recorded. The three years after that actually came in lower, 887, 952, 914, and if you wanted to believe the curve had settled, the data let you believe it.
Then look at 2026. We are only through six months of Patch Tuesdays. Half the calendar. And the count already stands at 1,380 CVEs. That figure does not even include the roughly 480 additional bugs disclosed separately in Chromium and Microsoft Edge this year. I will leave that thread for another day, but it tells you the 1,380 is a floor, not a ceiling.
We have not finished half the year, and we have already passed the highest full year total Microsoft has produced in two decades. Not close to it. Past it, by more than a hundred.
Do the math plainly, because the plain math is the argument. If the second half of the year adds vulnerabilities at nothing faster than the same pace we just watched in the first half, 2026 closes somewhere near 2,700. That is not a new record. That is more than double the old one, set in a single year, inside a dataset that took two decades to reach its previous peak.
This is what a step change looks like when it stops being a phrase in a blog post and starts being a line on a chart. I have spent thirty years reading vulnerability trends and telling clients to expect gradual increases they could plan a budget around. I did not expect to be sitting here, only halfway through the year, already writing about a number that broke twenty years of history before the second half even started.
A number this size is not proof by itself. Volume only becomes an apocalypse once exploitation and damage catch up to it, and that is exactly what the rest of this article is about.
The Other Half of the Proof
This year’s Verizon Data Breach Investigations Report supplies the half the Microsoft number cannot show on its own.
Exploitation of vulnerabilities has overtaken credential abuse as the most common way breaches actually begin. It now sits at 31 percent of known entry points, while credential abuse, the vector that led for years, has fallen to 13 percent. That is not a small shift in a chart. It is the leading cause of breaches changing hands, from a technique that steals what already exists to one that finds what nobody has fixed yet.
Remediation moved the wrong way at the same time. Only 26 percent of the critical vulnerabilities sitting on CISA’s Known Exploited Vulnerabilities list were fully patched last year, down from 38 percent the year before. The median time to fully close a critical vulnerability rose to 43 days, up from 32. And the backlog itself grew. The typical organization carried 50 percent more critical vulnerabilities waiting to be patched compared with the year before.
Exploitation is rising exactly as remediation is slowing down, and the queue behind both keeps growing. That is not two separate problems sitting next to each other by coincidence. That is the friction this article keeps describing, showing up in the one dataset built specifically to measure how breaches actually happen, not just how many vulnerabilities get published.
The Race After the Patch Ships
Here is the part that surprises people who assume a patch is the end of the story. A patch is not the end of the story. It is a new beginning for the attacker.
The moment a vendor ships a fix, the fix itself becomes evidence. An analyst can compare the old code to the new code, line by line, and see exactly what changed. That difference points directly at the flaw the patch was built to close. This practice has a name in the industry, patch diffing, and it has quietly produced a large share of real world exploitation for years, because plenty of attackers do not wait for a zero day. They wait for Tuesday, then reverse engineer Wednesday’s homework.
It used to take real skill and real time. Days, sometimes weeks, to go from a released patch to a working exploit. That gap was never generous, but it was something. Many organizations built their entire remediation plan around outrunning it.
AI compresses patch diffing into hours. Feed a model the before and after of a patch and it can often locate the fix, reconstruct the flaw, and produce a working proof of concept before most change advisory boards have finished their weekly meeting. The skill that used to gatekeep this work is disappearing. What is left is speed, and speed now favors whoever reads the patch first, not whoever wrote it.
This is why the final issue is always patching, no matter how well everything before it went. Say the vendor is disciplined. Say the disclosure is clean, the patch is well tested, and the system in question is fully in support, current, with nothing legacy anywhere near it. None of that guarantees the patch reaches production before someone on the other side reverse engineers it into a weapon. Vendor speed was never the bottleneck. Our speed was, and still is.
More Cases Than the Textbook Admits
It is tempting to believe this problem only lives in old, unsupported, forgotten systems. It does not. Fully supported environments carry their own friction, and it shows up in more places than most vulnerability programs plan for.
A bank running a current, fully supported core system still has to route every patch through a change advisory board, a staging environment, and a maintenance window that only opens once a month. The vendor shipped the fix on time. The organization’s own governance is what adds the three week delay, not a single legacy component in sight.
A hospital running medical devices on a fully supported operating system cannot simply apply the vendor’s patch, because the device manufacturer has to certify that update first, and that certification cycle runs in months, not days. The operating system vendor did everything right. The ecosystem wrapped around the device was never built to move at patch speed.
A retailer with a few thousand point of sale terminals, all current, all in support, cannot push a single patch to every terminal simultaneously without risking a failed rollout in the middle of a business day. The update goes out in waves, and every terminal still waiting in that queue is exposed for exactly as long as its wave takes to arrive.
A software vendor who bundles someone else’s patched component inside their own product has to recertify their own release before customers can safely update. The delay does not belong to the original vendor and does not belong to the customer. It belongs to the layer in between that nobody built a timeline around.
None of these organizations are running legacy technology. Every one of them is fully supported, fully current, and still exposed for longer than the threat actor needs. Patching was always the ceiling on how fast we could move, even when everything upstream of us worked exactly as intended.
The Second Compounding Force
If AI models are the accelerant, legacy systems are the dry wood. Every organization I have worked with carries a layer of infrastructure nobody wants to touch. Old operating systems that run one critical process nobody dares to migrate. Applications with no available patch because the vendor stopped supporting them years ago. Industrial control systems that cannot be taken offline without shutting down a plant. These systems were already the slowest part of any patching cycle before this new wave of vulnerabilities arrived.
Now overlay a faster discovery cycle and a faster exploitation cycle on top of an environment that cannot move any faster than it already does. The gap does not just persist. It widens on both ends at the same time. Discovery races ahead. Remediation stays anchored to the same slow, careful, often justified caution that legacy systems have always required.
This is the part of the Vulnpocalypse that rarely makes it into the headlines, because it is not glamorous. Nobody writes an exciting story about a fifteen year old database that cannot be patched without breaking a supply chain. But that unglamorous system is exactly where the next major breach is more likely to start. I have said before that the biggest risk in an organization is rarely the newest system. It is the one everybody stopped paying attention to.
Legacy systems turn a step change in vulnerabilities into a permanent structural deficit. You cannot out patch a problem when part of your estate was never built to be patched quickly in the first place.
Anton’s Fifteen Minute Question
Imagine you wake up tomorrow and, by pure magic, every vulnerability in your environment can be patched within fifteen minutes of the fix being released. Servers, applications, operating systems, all of it. The dream has come true.
Now do the hard part. Reverse engineer that reality.
What would have to be true about your environment for a fifteen minute patch window to actually work. Which systems would have to be rebuilt. Which approval steps would have to disappear. Which dependencies would have to be broken on purpose, long before any vulnerability ever showed up.
Run that exercise honestly and you will not land on fifteen minutes. Almost nobody will, and Anton is not pretending otherwise. But you will find a list of the exact places where your organization chose convenience over speed, one decision at a time, over years. The magic wand was never the point. The list you build while explaining why you cannot use it is.
That list is a better roadmap than any maturity model I have seen, because it is built from your own architecture instead of somebody else’s framework. It tells you precisely where the fifteen minutes disappear, and every one of those places is a place you could, in theory, choose to fix.
Naming It Changes How We Fight It
Anton did something extremely valuable by giving this moment a name. Naming a phenomenon forces a room full of executives to stop treating it as noise and start treating it as a distinct problem that needs a distinct response. I wanted to sit with the name a little longer, and see if it could carry the weight of what is actually happening, not just the count of vulnerabilities, but the friction that turns volume into damage.
A rapid step change in vulnerabilities is a headline. Structural friction in patching, colliding with legacy systems that cannot move, while AI compresses the time attackers need to weaponize a flaw, that is a crisis.
We are not short on vulnerabilities to worry about. We have never been short on those. What we are short on is the organizational speed to close the gap before it is used against us. That gap is not new. It has simply never had this much pressure behind it, or this little patience for our old excuses.
The flood was never about the rain. It was always about the crack in the dam we never sealed.
References
Chuvakin, A. (2026). Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. Medium. https://medium.com/anton-on-security/breaking-the-patch-sound-barrier-your-vulnerability-remediation-will-not-keep-up-ai-exploit-speed-b41116c4e92b
Chuvakin, A. (2026). Breaking the Patch Sound Barrier, Part 2: So Is the Apocalypse Coming, and What Is It. Medium. https://medium.com/anton-on-security/breaking-the-patch-sound-barrier-part-2-so-is-the-apocalypse-coming-and-what-is-it-dff70b2f09bd
Verizon. (2026). Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/2026-dbir-data-breach-investigations-report.pdf
Castro, J. (2025). The Asymmetry That Defines Cybersecurity: Lessons from a Linux Vulnerability and the KEV List. ResearchGate. https://www.researchgate.net/doi/10.13140/RG.2.2.35664.62725 DOI:10.13140/RG.2.2.35664.62725