98.5% of CVEs Are Never Exploited: How to Prioritize in 2026

For three decades, the industry told you to patch everything. The data says that advice cost you more than it protected you.

TL;DR: Roughly 98.5% of all known CVEs have never been exploited in the real world, a number Jeremiah Grossman and Robert Hansen laid out on the Down the Rabbit Hole podcast. For years, vulnerability management defaulted to scanning, scoring, and patching everything on a maintenance window, regardless of exploitation evidence. That approach made sense before anyone had real data on attacker behavior. It does not make sense anymore. This post breaks down the shift from CVSS-score thinking to exploitation-evidence thinking, and why that shift is exactly what separates a junior-sounding vulnerability management answer from a senior one in an interview.

Jeremiah Grossman opened a recent episode of the Down the Rabbit Hole podcast with a number most security teams have never heard said out loud. Robert Hansen, his co-host at Root Evidence, thinks the real number is even lower once you count vulnerabilities that never got a CVE assigned at all. Together with host Raphael Mudge, the two spent an episode walking through why an entire industry built its habits around a threat model that almost never shows up, and what changes once you prioritize by evidence instead of by score. Listen to the full conversation on Down the Rabbit Hole, but the practical version fits in one post: stop asking how severe a vulnerability sounds on paper, and start asking whether anyone is using it.

Jump to a section:

• What does “98.5% of CVEs are never exploited” mean?
• Why did vulnerability management default to “patch everything, always”?
• What happens when you patch a “perfect 10” that was never going to be exploited?
• CVSS score vs. exploitation evidence: what tells you more about real risk?
• What is CISA’s KEV catalog, and how do you use it?
• What does it sound like when someone understands vulnerability prioritization?
• Why doesn’t the vulnerability management industry police itself?
• What should you do with this before your next patch cycle?

What does “98.5% of CVEs are never exploited” mean?

It means almost every vulnerability a scanner flags will never appear in an actual attack. Grossman and Hansen tie the real exploited share to insurance-claims data at Root Evidence, and put it below 1.5%, likely lower still.

Grossman opened the episode with that number: roughly 98.5% of all known CVEs have never been exploited in the wild. Hansen added the harder part. The true percentage is likely lower once you count the flaws that never got a CVE assigned in the first place. That means the overwhelming majority of the findings on a scan report, the ones that trigger maintenance windows, change-control tickets, and after-hours patch cycles, are statistically never going to be used against you.

Mudge, the creator of Cobalt Strike and host of the show, framed this with a mechanic analogy that lands hard once you sit with it. A mechanic hands you a list of seven urgent problems with your car. You fix none of them. Three hundred thousand miles later, nothing has happened. That is not proof the mechanic was lying. It is proof that “urgent” and “will cause a problem” are two different claims, and vulnerability management has treated them as the same claim for thirty years.

Why did vulnerability management default to “patch everything, always”?

Cybersecurity built its habits during decades with no real visibility into attacker behavior, so the field defended against every hypothetical threat, including a highly sophisticated attacker who rarely showed up. Insurance-claims data now shows what attackers did.

Grossman traces this back to history rather than incompetence. When vulnerability management practices formed, nobody had good data on what attackers chose to exploit. So the field defaulted to a worst-case posture: protect against everything, including the most sophisticated attacker imaginable, because there was no way to rule anyone out.

That posture made sense given the information available at the time. It does not make sense now. Cyber insurance carriers process breach claims by the thousands and track the root cause of every one. Root Evidence pulled that claims data together with Grossman and Hansen and found something specific: 619 CVEs account for 30 to 40 percent of all cyber insurance claims tied to remotely exploitable vulnerabilities. You do not need their exact list to take the lesson. A small number of vulnerabilities do almost all the damage, and CVSS score alone does not tell you which ones they are.

What happens when you patch a “perfect 10” that was never going to be exploited?

Mudge patched a vulnerability that scored a perfect 10 on CVSS and broke a card-processing system for 36 hours. He believes that specific flaw was never going to be exploited in that environment.

Mudge shared a personal story from his own enterprise experience. His team patched a vulnerability that scored a perfect 10 on CVSS. The patch broke a card-processing system for 36 hours. Mudge does not think that flaw was ever going to be exploited in that environment. A perfect score told the team almost nothing about the real risk they were carrying, and it cost them a day and a half of outage on a system that handles money.

This is the part vulnerability management rarely admits out loud. Patching is not free. Every emergency patch competes with a maintenance window, a change-control process, and a team’s attention. Spending that budget on a flaw with no real attack path is not caution. It is a cost with no corresponding benefit.

CVSS score vs. exploitation evidence: what tells you more about real risk?

No. CVSS measures theoretical severity, not real-world use. CISA’s free KEV catalog lists vulnerabilities with confirmed active exploitation, a stronger, evidence-based signal you check yourself before burning a maintenance window.

CVSS tells you how severe a vulnerability sounds on paper. It does not tell you whether anyone is using it. That distinction is the entire argument Grossman and Hansen make on the podcast, and it is the distinction the industry spent three decades treating as unimportant.

Here is the practical version, laid out side by side:

You do not need Root Evidence’s proprietary list of 619 CVEs to apply this lesson. CISA’s KEV catalog is public, free, and gives you the same evidence-based signal for the price of a bookmark.

What is CISA’s KEV catalog, and how do you use it?

CISA’s Known Exploited Vulnerabilities catalog is a free, public list of CVEs with confirmed evidence of active exploitation. Cross-reference your scan results against it before you prioritize anything by CVSS score alone.

CISA maintains the Known Exploited Vulnerabilities (KEV) catalog, a public list of CVEs with confirmed evidence of active exploitation. Federal agencies must remediate anything on it within a set deadline, but nothing stops you from using it the same way.

The workflow is simple, and you start today:

• Pull your current vulnerability scan report.
• Cross-reference every finding against the KEV catalog.
• Anything that matches gets prioritized first, regardless of its CVSS score.
• Everything else gets triaged on business context (internet-facing, holds sensitive data, sits on a critical path) instead of a single number.

This is not a replacement for judgment. It is a floor. Grossman and Hansen’s argument, backed by insurance-claims data instead of a public list, adds a second layer on top: a small number of specific CVEs, 619 in their analysis, account for 30 to 40 percent of all cyber insurance claims tied to remotely exploitable vulnerabilities. That data is proprietary. KEV is not. Start with what you check yourself.

What does it sound like when someone understands vulnerability prioritization?

A junior answer says, “I patch every critical CVSS score.” A senior answer says, “I check whether something has a confirmed attack path before I burn a maintenance window.” One follows a checklist. The other understands risk.

This is where the myth-busting meets your resume. Hansen’s point on the podcast about vendor incentives is also a hiring signal in disguise. If you answer a vulnerability management question in a security interview with “I patch every critical CVSS score,” you have described a checklist, not a skill. Hiring managers hear that answer constantly, and it tells them you follow instructions. It does not tell them you understand risk.

Compare it to this: “I check whether a vulnerability has a confirmed attack path, cross-reference it against CISA’s KEV catalog, and weigh that against the business context of the affected system before I decide what gets prioritized in the next patch cycle.” That answer says something different. It says you know CVSS score alone is not risk. It says you know the difference between a flaw that sounds bad on paper and a flaw being used against organizations right now. It says you would push back on a blanket patch-everything mandate if the evidence did not support it, and explain why.

You do not need three decades of experience to sound like this. You need to understand the gap Grossman and Hansen are describing: exploitation-evidence thinking, not CVSS-score thinking. That single reframe turns “I follow the scanner’s output” into “I make a defensible call and explain it.”

If you are still building toward that first role, the shift matters even more. Certifications and CVSS trivia get you through an ATS filter. A clear, evidence-based answer to “how do you prioritize vulnerabilities” is what gets you through the human conversation after it. If you want the fuller picture of what hiring managers are screening for beyond this one question, our cybersecurity career guide covers the rest, and this breakdown of breaking in with no formal experience is worth reading next.

Why doesn’t the vulnerability management industry police itself?

Nobody profits from telling you a scanner or a security product does not reduce your real risk. Hansen says security professionals estimate only 20 percent of RSA and Black Hat products would reduce financial loss if they worked as advertised.

Hansen asks security professionals a simple question at conferences: what percentage of the products at RSA or Black Hat would reduce financial loss if they worked exactly as advertised? The average answer is 20 percent. Not from cynics outside the industry. From the people who work inside it.

Vendor budgets chase competitor feature lists instead of attacker behavior, because there is no penalty for selling a scanner that surfaces a million findings nobody needs to act on. Nobody, including the analyst firms that rank these products, has a financial reason to tell a customer their purchase does nothing. The incentive gap is not a conspiracy. It is structural, and it is why “we bought the tool” and “we reduced risk” are not the same sentence.

The same gap shows up inside security teams, not only in the vendor market. A CISO protecting their own career defaults to patch everything, because any unpatched item becomes personal exposure if something goes wrong later. A CISO acting in the company’s real interest might make a more selective, defensible call instead, backed by evidence rather than a blanket policy. Hansen and Grossman expect CFOs to start pushing on vulnerability management budgets once they realize how much of that downside is already covered by cyber insurance, and they expect that conversation to be uncomfortable for security leaders who spent years telling their boards everything must be patched.

Worth noting for anyone chasing the newest headline instead of fundamentals: the same episode pushes back on AI-driven attack hype. Hansen asked eight different cyber insurance carriers how many claims they were able to attribute to AI use by attackers, outside of phishing. The answer across all eight was zero. Attackers who lean on AI mid-attack risk leaving a detectable trail, which makes AI-heavy attacks a bad bet for anyone trying to stay unnoticed. If a hiring manager tests you on threat trends instead of fundamentals, exploitation-evidence thinking beats AI-hype thinking there too.

What should you do with this before your next patch cycle?

Cross-reference your next scan report against CISA’s KEV catalog before you patch anything by CVSS score alone. Then rank the KEV matches by business context, patch those first, and document why everything else waited.

1. Pull your latest vulnerability scan and cross-reference it against CISA’s KEV catalog.
2. Rank the matches by business context: internet-facing, holds sensitive data, sits on a critical path.
3. Patch those first, on a real timeline, not “everything, immediately.”
4. For everything else, write down the reasoning for why it waits. That documentation is what makes a selective call defensible instead of negligent.
5. If your interview answer, or your team’s process, still starts and ends with a CVSS number, that is the exact gap this podcast episode is describing.

Grossman and Hansen tie all of this to their book, The End of Guessing, and to a warranty product built on the same insurance-claims data. You do not need to buy anything to use the underlying lesson. The industry spent three decades guessing at risk because nobody had the data to do anything else. That excuse is gone. If you want to see this same evidence-over-guesswork shift playing out in a different corner of vulnerability management, our recent piece on third-party risk and the flood of AI-generated bug reports covers the same problem from the vendor side.

Listen to the full conversation on Down the Rabbit Hole for the complete argument, including the specifics on the 619 CVEs and the insurance-backed warranty model.