The CVE Flood Is a Lie: How to Hunt When AI Dumps 36% More Bugs But Exploitation Only Grows 10%

Your vulnerability scanner ran overnight. Your inbox has 47 new CVE alerts. Slack is pinging you about a "critical" flaw in a library you have never heard of. Someone on LinkedIn posted a thread that makes it sound like the internet is on fire.

Take a breath. Most of that noise is not your problem today.

In Q2 2026, disclosed vulnerabilities jumped about 36% quarter over quarter, largely because AI-assisted research went mainstream. At the same time, the number of vulnerabilities confirmed as actively exploited in the wild only grew about 10%. Rapid7 counted more than 8,500 new high and critical CVEs in one quarter - while newly exploited issues held roughly steady at around 40.

The flood is real. The panic is optional. This post is a simple, practical workflow for hunters and defenders: what to ignore, what to chase, and how to decide in 15 minutes on a Monday morning without burning out.

TL;DR

• Disclosures spiked in 2026 because AI scales research. Exploitation in the wild did not spike at the same rate.
• Stop triaging by CVSS alone. Use four filters in order: KEV → EPSS → internet exposure → pre-auth / no-click.
• Hunters: do not chase every fresh CVE thread. Chase reachable, exploitable, under-tested surfaces - logic bugs, auth gaps, misconfigs AI scanners skim past.
• Defenders: patch what attackers can reach without a password first. About 62% of exploited vulns this year needed no user interaction.
• If you only bookmark one tool: use a KEV + EPSS lookup before you panic. We built one at securitycipher.com/cve-lookup.

What actually changed in 2026 (the numbers, plain English)

Here is the headline everyone is reacting to: agentic AI turned vulnerability research into a volume game. Beazley Security's Q2 2026 report ties a 36% jump in new disclosures to AI-assisted research programs going operational. HackerOne paused the Internet Bug Bounty citing AI-assisted volume. NIST stopped enriching every single new CVE entry. Pwn2Own rejected applicants for the first time. Cisco reworked its disclosure model.

That sounds apocalyptic until you look at the other line on the chart. CISA's Known Exploited Vulnerabilities catalog grew about 10% in the same window. Rapid7's Q2 data shows disclosure volume roughly doubling year over year while the count of newly exploited issues stayed flat.

Translation: we are finding more bugs. Attackers are not magically exploiting all of them overnight. The hard part was never "does a bug exist somewhere in the ecosystem." The hard part is still "can an attacker reach it, weaponize it, and get paid for the effort."

Meanwhile, the boring old ways of breaking in still work. Beazley found compromised credentials in 67% of ransomware cases they investigated. AI made the CVE feed louder. It did not retire phishing, stolen sessions, or default passwords.

Why the CVE flood feels worse than it is

Three things are stacking on top of each other:

1. Volume. More scanners, more AI-assisted fuzzing, more duplicate reports hitting the same root cause from different angles.
2. Speed of PoCs. Flashpoint reported that nearly one in five H1 2026 disclosures shipped with working exploit code. A scary CVE on Tuesday can have a public PoC by Wednesday.
3. Alert fatigue. Every vendor subject line says CRITICAL. Your brain stops distinguishing "internet-facing RCE with KEV entry" from "local-only info leak in a driver you do not ship."

The fix is not "read faster." The fix is a smaller inbox by design. You need a filter stack that throws away 95% of the feed before it hits your frontal lobe.

The 4-filter stack (use this in order)

When a new CVE lands, run it through these four questions. Stop as soon as you have a clear answer. Most CVEs die at filter one or two.

Filter 1: Is it on the CISA KEV list?

CISA's Known Exploited Vulnerabilities catalog is the closest thing we have to a government-backed "this one is not theoretical" list. If a CVE is on KEV, someone is paying attention because exploitation is confirmed or expected imminently.

Action: patch or mitigate KEV entries on internet-facing assets first. Full stop. Everything else waits.

Filter 2: What is the EPSS score?

CVSS tells you how bad a bug could be. EPSS (Exploit Prediction Scoring System) estimates how likely exploitation is in the next 30 days, based on real-world signals. A CVSS 9.8 that nobody is touching is less urgent than a CVSS 7.2 with a climbing EPSS and a public PoC.

Rough rule of thumb I use:

• EPSS below 0.05: note it, do not lose sleep.
• EPSS 0.05 - 0.20: track it, patch on your normal cycle if exposed.
• EPSS above 0.20 with a public PoC: treat it like a fire drill if the asset is reachable.

You can look up EPSS alongside NVD, OSV, and KEV status in one shot on our CVE Lookup page instead of juggling five tabs.

Filter 3: Can an attacker actually reach it?

A critical RCE in a component you do not run is a zero-day for your threat model. This sounds obvious, yet most CVE panic threads skip the inventory step entirely.

Ask plainly:

• Do we run this product or library version?
• Is it on a host reachable from the internet?
• Is it behind auth, VPN, or a bastion that attackers rarely get through?
• Is it a dependency buried three layers deep that never parses untrusted input?

No exposure, no emergency. Log it and move on.

Filter 4: Does it need a user to click, or is it pre-auth?

Rapid7 reported that 62% of exploited vulnerabilities in Q2 2026 required no user interaction - no phish, no stolen creds, no "please open this PDF." Missing-authentication flaws (CWE-306) disclosures surged 247% year over year.

If a bug is pre-auth, network-reachable, and has exploit code floating around, it jumps to the front of the line. If it needs a local shell or a user clicking through three prompts, it is still important - just not "wake up the on-call at 2 AM" important unless you are already compromised.

The 15-minute Monday workflow (copy this)

I do this every week before I read a single Twitter thread about "the worst CVE of the year."

Step 1: Pull the KEV delta (2 minutes)

See what CISA added recently. If you run a SIEM, ingest the KEV feed. If you are a solo hunter or a small team, a quick curl is enough to sanity-check volume:

curl -sL https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); v=d['vulnerabilities']; print(len(v), 'total KEV entries'); print(); print('Latest 3 additions:'); [print(f\"  {r['cveID']}  {r['dateAdded']}  {r['vendorProject']}/{r['product']}\") for r in sorted(v, key=lambda x: x.get('dateAdded',''), reverse=True)[:3]]"

Cross-check new KEV IDs against your asset inventory (or your bug bounty scope). Anything that matches goes on the "today" list.

Step 2: EPSS spot-check on anything trending (3 minutes)

When a CVE is blowing up on infosec Twitter, look up its EPSS before you retweet the panic:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-73570" | python3 -m json.tool

Or paste the ID into CVE Lookup and read KEV + EPSS + affected products in one screen.

Step 3: Prove exposure (5 minutes)

For defenders, map the CVE to installed versions (SBOM, package lockfiles, CMDB, whatever you have). For hunters, map it to in-scope tech on programs you care about.

Quick external exposure check on a hostname list:

cat scope.txt | httpx -silent -status-code -title -tech-detect -o live.txt

If the vulnerable product fingerprint does not show up on anything you own or are allowed to test, downgrade the urgency.

Step 4: One focused hunt block (5 minutes)

Pick one KEV or high-EPSS issue that matches your stack. Read the vendor advisory, not the hot take. Run a targeted check (version banner, nuclei template, manual repro on a lab). Write down "affected / not affected" and close the tab.

nuclei -tags kev,cve -u https://YOUR-TARGET -severity critical,high -stats -silent

That is it. You are now more informed than 90% of the people quote-tweeting the CVE.

If you hunt bugs: what to chase when the feed is loud

The CVE flood changes your strategy, but not in the way the doomer posts claim. You do not need to become a CVE librarian. You need to go where the automated flood is not.

Chase these

• Fresh KEV on tech in your program scopes. If Zimbra, SharePoint, or an edge appliance lands on KEV and your target runs it, that is a paid engagement, not a news article. We covered the patch-now mindset in our 24-hour startup pentest guide - same energy, narrower target.
• Missing auth on "internal" APIs. CWE-306 is having a moment for a reason. Admin panels, debug routes, GraphQL introspection on staging that mirrors prod - hunt here while everyone else refreshes NVD.
• Business logic. Coupons, credits, race conditions, workflow skips. No CVE will ever capture "you can checkout for $0 if you click fast enough."
• AuthZ bugs (IDOR, BOLA). Scanners find some. They miss most of the interesting ones because impact needs two accounts and a story. Our Codex Security lab write-up is a good reminder: automation finds patterns, humans still prove business impact.

Ignore these (for now)

• CVE threads for products not in your scope and not on KEV.
• Duplicate scanner output that does not reproduce manually.
• "Critical" local-only bugs on endpoints you do not control in a web program.
• AI-generated report templates without a working PoC on the actual target.

We went deeper on the economics of this in Is AI Killing Bug Bounty? Short version: volume is cheap, signal is expensive. Be the signal.

If you defend: patch order that survives the flood

When everything is "critical," nothing is. Use this order until your backlog is under control:

1. KEV + internet-facing + pre-auth. Example from August 2026: Zimbra CVE-2026-73570 (SMTP to RCE, KEV deadline). If you run it, patch before you read another thread.
2. KEV + internet-facing + needs creds. Still urgent, but attackers need a foothold first.
3. High EPSS + public PoC + exposed. Not on KEV yet, but watch closely.
4. Everything else on a normal cycle. Yes, really.

Pair this with credential hygiene. Rotate secrets after incidents, enforce phishing-resistant MFA on admin paths, and monitor for stolen session tokens. The CVE feed will not remind you that 67% of ransomware still starts with compromised credentials - but your incident runbooks should. See our incident response playbooks if you need a starting template.

How to stop your scanner from becoming part of the problem

Default scanner policies are built for compliance PDFs, not for humans with a finite attention span. Tighten them:

• Tag-driven scanning. Run KEV-tagged nuclei templates against external assets on a schedule, not the entire template corpus daily.
• Dedupe by root cause. Ten CVEs for the same vulnerable OpenSSL build is one patch task.
• Suppress local-only findings on appsec dashboards meant for internet risk.
• Require exposure context in tickets: hostname, port, auth required, proof snippet.

Example targeted external scan:

nuclei -tags kev,cve -u https://app.example.com -severity critical,high

You will get fewer rows. That is success.

Bottom line

The CVE flood is not a reason to quit security work. It is a reason to stop treating every advisory like a personal attack. AI dumped more bugs into the public record. Attackers still pick the reachable ones, still love stolen passwords, still move fastest on pre-auth edge boxes.

Your job is smaller than the feed makes it feel: KEV first, EPSS second, exposure third, panic never. Everything else can wait until coffee number two.