Request a Demo

There Is Still No Such Thing as a Zero Day: Staying Ahead of the Vulnpocalypse - Atomicorp - Own Your Security. Protect Your Data.

There Is Still No Such Thing as a Zero Day: Staying Ahead of the Vulnpocalypse

Posted on by Mike Shinn

The zero day claim, 20 years on, and the amassing vulnpocalypse

About twenty years ago I told a conference audience that there is no such thing as a zero day. I meant it then and I mean it more now. A “zero day” is a fact about the vendor’s calendar: the bug became public before the patch did. It is not a fact about your security. The vulnerability was in your system the day you installed the software. You were already exposed. The disclosure didn’t change your risk, it changed your awareness of it.

That distinction used to be a nitpick I made at conferences. In 2026 it is the whole ballgame. The industry built its vulnerability management model on the opposite assumption: that security is the state you reach by knowing about CVEs and patching them fast enough. That model has now hit its physical limit, and the people running it can feel it. They call it the vulnpocalypse. I’d call it the bill coming due.

This piece revisits the original argument, checks it against what has happened since, and says plainly what I got right, what I missed, and what you should do instead of refreshing your CVE feed.

What I argued then

The original piece made three claims. First, “zero day” is a term we inherited from the warez scene, where it meant a release that beat the publisher to market. Security borrowed it to mean a vulnerability that beat the vendor’s patch. In both uses it describes timing, not severity. Second, there are only two kinds of “new” vulnerability: a new instance of a method we already understand (another SQL injection, another command injection, another buffer overflow, etc.), or a new method nobody has defended against before. The first kind is almost all of them. The second kind shows up a handful of times a decade. Third, if you build your defenses around methods and root causes rather than around individual vulnerabilities, the first kind becomes a non-event and the second kind is what your security program is actually for.

The practical corollary was blunt: you will always have vulnerable software. Plan on it. A program that depends on knowing every hole before the attacker does will lose, because that is not a race defenders can win. A program that assumes the holes are there and controls what an attacker can do through them can win, and does.

I wrote that at a time a bad year meant a few thousand CVEs. The argument didn’t depend on the number. It depended on the ratio of methods to vulnerabilities, and that ratio has only gotten more lopsided.

The vulnpocalypse, by the numbers

The CVE-chasing model didn’t fail gracefully. It failed on a schedule you can read off a chart. 48,185 CVEs were published in 2025, up 20.6% on 2024, which was itself a record. FIRST’s mid-year revision now puts 2026 near 66,000, about 46% above their own January forecast, and the first seven months alone ran at roughly double the 2025 pace. The driver is AI-assisted discovery: Mozilla, Microsoft, Google, Fortinet and the rest are now pointing frontier models at their own code and filing what falls out.

The tracking infrastructure gave up first. On April 15, 2026, NIST formally stopped trying to enrich every CVE. Submissions rose 263% between 2020 and 2025; NIST enriched 42,000 in 2025, its best year ever, and still fell further behind. Roughly 29,000 backlogged CVEs were reclassified “Not Scheduled,” meaning they will never get a CVSS score, a CPE, or any of the metadata every scanner on the market depends on. The NVD now enriches KEV entries, federal software and “critical software” as defined by EO 14028. Everything else is tagged lowest priority and left alone.

Read that again. The national vulnerability database has conceded that it cannot keep a complete inventory of vulnerabilities. If the people whose only job is cataloguing CVEs can’t keep up, a program whose security depends on keeping up with CVEs is not behind. It is structurally impossible.

Here’s the number that matters more than any of the others. Exploitation didn’t follow the curve. VulnCheck’s first-half 2026 data shows CVE volume up 45% half-over-half while confirmed exploited vulnerabilities rose 10%. The KEV-to-CVE ratio has fallen from 2.7% in late 2023 to 1.4%. Roughly 200 CVEs were exploited within 31 days of publication in H1 2026, in line with 2024 (196) and 2025 (194). Of 1,061 vulnerabilities attributed to AI-assisted discovery, 14 have confirmed in-the-wild exploitation. Anthropic’s Project Glasswing reported more than 23,000 findings; 126 became CVEs; one has been seen exploited.

So disclosure doubled and the thing you actually defend against stayed flat. That is not a coincidence. It is the ratio I was talking about twenty years ago, finally large enough that nobody can pretend it isn’t there.

Methods, not vulnerabilities

The reason the CVE-chasing model is losing has nothing to do with effort or tooling. It is arithmetic. There are tens of thousands of new vulnerabilities a year, and there are a few hundred ways to exploit them. MITRE’s ATT&CK v20 catalogues 227 enterprise techniques and 479 sub-techniques, and that list grew by a handful this year while CVEs grew by tens of thousands. CWE, the catalogue of weakness types, has sat under a thousand entries for years. The top five weakness classes in 2025, per Gamblin’s data, were cross-site scripting, injection, missing authorization, CSRF and SQL injection. Every one of those was in the OWASP Top Ten in 2004. Of 48,185 CVEs, 8,207 were XSS alone.

That is the whole argument in one table. The attacker’s menu is short and old. The vulnerability list is long and new. If you defend the menu, the list is noise. If you defend the list, you are trying to outrun a conveyor belt that the NVD itself just admitted it can’t keep pace with.

I’ll be concrete about what “defending the method” means, because the phrase gets abused. A method defense is a control that works against a class of exploitation regardless of which specific bug is being exploited. A WAF rule that recognizes command injection by its grammar stops the command injection in the CVE published this morning and the one that will be published next year. Mandatory access control that denies a web server the ability to spawn a shell stops the RCE whether it came through Struts, Log4j, a WordPress plugin or something nobody has named yet. Real-time file integrity monitoring catches the webshell being dropped, whatever got it there. Egress filtering that won’t let the database server talk to the internet makes the exfiltration step fail no matter how the attacker got in.

None of those controls need a CVE number to work. That is the point. They were already in place when the vulnerability was discovered, because they were put there for the method, and the method was known.

A “zero day” against a system defended this way is a bug for which there happens not to be a patch yet, being exploited through a technique the system already refuses. It gets logged. It does not get a war room.

20 years of running the experiment

I didn’t just write the argument down. We built a company on it. Atomicorp’s ModSecurity rules and Atomic OSSEC exist because I believed in 2006 that a defense written against methods would keep working against vulnerabilities that hadn’t been discovered yet, and the only honest way to find out was to ship it and wait.

The test we run now is public: research.atomicorp.com is a research site where we take a published CVE, generate exploit probes from it, replay those probes against a live WAF and EDR running our production rules, and publish the result when the rules block it. The part that matters for this article: the rules under test were written before the CVE existed. They are not virtual patches backfilled after disclosure. They are method rules, written for injection, traversal, deserialization, file inclusion and the rest, and the research notes are the record of how often a method rule stops a vulnerability it was never told about.

I want to be exact about what that site does and doesn’t claim, because the industry has a habit of turning “we blocked these” into “we block everything.” The research notes document selected positive findings. They are not a coverage matrix, a certification or a completeness claim. Some findings are detect-only and say so. There are CVEs the method rules don’t catch, and when we find one we write a new rule, which is the whole reason the rule set is still updated daily after two decades.

But the pattern across the notes is the thing I was arguing for in 2006, now with receipts: when a CVE lands and the exploit is a known method, the systems running method defenses were already protected the day the vendor found out. The zero day was a zero day for the vendor. For the defender it was a Tuesday.

It’s worth saying that the same principle is what the OSSEC side of the house is built on. OSSEC doesn’t know what CVE the attacker used. It knows a file changed in /var/www that shouldn’t have, a process spawned from a web server that has no business spawning, a log line that matches a known post-exploitation pattern. That is method detection. It is what you fall back on for the rare vulnerabilities whose method you didn’t anticipate, and it is what the original article called the moment your security program earns its pay.

What I got wrong, or didn’t see coming

The core claim held. Three things around it didn’t, or at least need updating.

I underestimated how completely the industry would build itself around the wrong model. In 2006 I thought the CVE-chasing approach was a bad habit that better thinking would correct. Instead it became the product category. Vulnerability management, patch management, exposure management, risk-based vulnerability management: an entire market, with its own compliance regimes, auditors and board slides, whose unit of work is the CVE. When NIST gave up on universal enrichment this April, the reaction from that market was to ask how to keep scanning without the metadata. The model is so entrenched that its own infrastructure failing didn’t prompt anyone to question the model.

I didn’t anticipate supply chain compromise at the scale it reached. The 2006 taxonomy would have filed “the vendor’s build system was backdoored” under trusted-insider, a known method. That’s technically right and practically useless. SolarWinds, xz, the npm and PyPI worms of the last two years: these are method-level events, but the method is “abuse the trust you extended to a dependency,” and most organizations have never built a control for that at all. Method defense works here too, but the method is one almost nobody is defending. That’s a gap in the program, not in the argument.

I didn’t foresee that discovery would become cheap before fixing did. I expected vulnerability counts to grow with software. I did not expect a frontier model to point itself at Firefox and file 271 bugs for one release, or Microsoft to ship 663 CVEs in a single Patch Tuesday. AI didn’t create a new method. It created a volume multiplier on the old ones, and that multiplier is the thing that broke the queue. It also cuts both ways: the same tooling now writes detection signatures and method rules faster than humans could, which is why the next few years will be decided by whether defenders use it to defend methods or waste it triaging CVEs.

And one thing I’d soften. The original piece was a little glib about new methods being rare. They are rare, but when one shows up it tends to be a decade-defining event: Spectre, the first prompt-injection chains against agentic systems this year, the MCP vulnerability wave in July. The rarity is real. The cost when it happens is why you build detection and response for the cases prevention didn’t anticipate.

What to do instead of chasing CVEs

This is it, compressed, because the answer hasn’t changed and doesn’t need five thousand words.

The approach has a name, and it is older than the CVE program: defense in depth. It gets dismissed as a cliché because it is usually explained as “more layers,” and that misses what it commits you to. Defense in depth is built on the assumption that any single control will fail, which is the same thing as assuming you are already compromised. Not as a slogan, as a design constraint. You will run vulnerable software. You run some now that has a CVE nobody has filed yet. Every control you build should still do its job on the day that CVE is published, and it should still do its job on the day the control in front of it doesn’t.

  • Inventory your methods, not your CVEs. Take the ATT&CK techniques and CWE classes that actually apply to your stack, which is a few dozen, not a few hundred, and for each one answer three questions: do I prevent it, do I detect it, and what happens if neither works. That list fits on two pages. It is the only vulnerability management document that stays true for more than a week.
  • Put method controls in front of everything that faces the network. These controls include a WAF with real method rules, not a CVE signature feed, and also mandatory access control on the services that get exploited, so a successful exploit lands in a box with nothing in it. The third control should be egress filtering so the box can’t call home. These three controls, done properly, neutralize the exploitation step for the majority of the KEV catalogue before you have read the advisory.
  • Detect at the method layer too. Orchestrate real-time file integrity on the paths attackers write to. Process ancestry so a shell under a web server is an alert, not an event in a log nobody reads. Baseline the traffic patterns of your systems so the anomaly shows up as an anomaly. This is the layer that catches the new method, the one you didn’t have a prevention rule for, and it is the layer that turns a breach into an incident report instead of a disclosure.
  • Then, and only then, patch by exploitation, not by severity. Use KEV and EPSS to decide what to patch first, and let CVSS 9.8 instances that no one is exploiting wait their turn behind a 6.5 that is in active use. CISA’s BOD 26-04 now says essentially this for federal agencies. The patch queue is maintenance, not defense. Treat it accordingly.
  • Have the recovery plan the original article promised and rehearse it. The rare true zero-day method will get past prevention and may get past detection. What determines whether that ends your quarter or your company is whether you can rebuild, restore and re-establish trust in a system whose compromise you did not see coming. Backups you have tested, images you can redeploy, credentials you can rotate in an hour. That is the spare tire.

None of this is new. All of it was available in 2006. The difference is that in 2006 you could still get away with ignoring it and chasing CVEs. In 2026 you can’t, because the CVEs are arriving faster than anyone can chase them and the organizations that catalogue them have said so in writing.

There is still no such thing as a zero day

The term describes when the vendor found out. It says nothing about whether you were vulnerable, because you were, and nothing about whether you were protected, because that depends on what you built, not on what got published.

The vulnpocalypse is real as a data problem. It is not a security problem for anyone who stopped treating the CVE list as their security program. Sixty-six thousand CVEs this year will be exploited through a few hundred techniques, almost all of which have names, documentation and well-understood countermeasures. Defend those. Detect those. Plan for the handful you can’t. That is defense in depth, and it was the answer in 2006 too. Then let the feed scroll.

Learn more about Atomicorp’s vulnerability management capabilities.

Request a Demo.

Visit our CVE and security research tools page.

 

Sources