The vulnerability backlog on your dashboard is misleading. Google Threat Intelligence Group recorded monthly disclosures rising from 5,045 in January 2026 to 10,740 in August, yet attackers exploited 141 of roughly 60,000 flaws disclosed across the period, about one in 431. Meanwhile, the critical-severity share fell from about 13 percent to 7 percent.
AI industrialised vulnerability discovery without accelerating remediation, converting your backlog from deferred maintenance into an unpriced exposure surface. How much risk you carry depends on throughput, specifically how quickly you can verify and ship fixes.
The six pieces below follow that asymmetry through the arithmetic of the flood, the maintainer bottleneck, the noise, the clock, the ordering and the budget. If you want the counters before the argument, the arithmetic of the flood is the natural entry point.
Why is vulnerability disclosure volume growing so much faster than anyone’s ability to patch?
Direct Answer
Disclosure volume roughly doubled in eight months, rising from 5,045 monthly public disclosures in January 2026 to 10,740 in August, while only 141 of roughly 60,000 flaws disclosed across the period saw confirmed in-the-wild exploitation, about one in 431. Discovery scaled with model capability; remediation stayed tied to human review. Treat raw counters as activity rather than risk, and verify who assigns identifiers before comparing volume across projects, vendors or years.
Industrial output drives this: Microsoft patched 1,407 CVEs in its October 2026 Patch Tuesday. A CVE is an identifier attached to a dated observation, not an indicator of weaponised risk.
Linux now approaches 2,000 CVEs per release, up from roughly 500 in the 6.x era, because its CVE Numbering Authority (CNA) labels nearly every bugfix, making a stable project look fragile. GitHub year-to-date issuance is up 476 percent for the same reason, as why disclosure is outrunning remediation explains. Upstream absorption comes next.
Who absorbs the flood when reports outnumber the people who can read them?
Direct Answer
Your queue ends in an open source maintainer’s inbox. Project Glasswing surfaced 1,596 findings across 281 projects by May 2026, yet only 97 confirmed patches followed. The binding constraint on the open source supply chain you depend on is upstream absorption capacity: every report still needs a human to read, reproduce and own it. That bottleneck decides how many reports become fixes.
When maintainers burn out, projects keep shipping without advisories, making silence look safe. curl ended its bug bounty over low-quality AI noise, and Google froze its programme after automated submissions overwhelmed staff. Programmes at that volume cannot triage noise, as what happens when maintainers stop patching explores.
Automated reporting generates low-effort submissions, and genuine findings still need triage, reproduction and an owner. Anthropic’s ledger recorded 29,439 candidate bugs yielding 516 upstream patches, under 2 percent. Ask whether a finding arrives with a reproducible proof of concept, as separating real bugs from AI slop explains.
Why has the exploit window collapsed, and why do fixed patch SLAs no longer hold?
Direct Answer
A disclosure records that a flaw exists. Exploitation is a separate event. The Cloud Security Alliance found that the median gap between public disclosure and weaponised exploitation dropped from 771 days in 2018 to single-digit hours, with 28.3 percent of exploited flaws weaponised within a day. Fixed schedules no longer hold, prompting CISA to replace its flat 14-day remediation deadline with risk-based windows as tight as three days.
Three intervals matter: fix to disclosure, disclosure to first exploitation, and patch availability to deployment across your estate. Only the second bounds how long a fix can wait. Most disclosures never see an attack; a few move within hours.
Automated patch diffing and model-assisted scripting compress weaponisation past your change-management cycle. Practical defence relies on risk-based windows driven by reachability, using network isolation and virtual patching to buy time for deployment. Our guide to the collapse of the exploit window explains.
Why do severity scores misorder risk, and what should you fix first instead?
Direct Answer
Base severity scores alone evaluate theoretical damage under worst-case assumptions, without knowing whether your code reaches vulnerable libraries or whether adversaries exploit them. When a backlog holds hundreds of high-severity alerts, ranking by score stops discriminating. You shrink queues by setting aside unreachable components, addressing confirmed active exploits first, and scheduling reachable items by predicted exploitation likelihood rather than severity band.
Base scores are context-free: an isolated 9.8 flaw in a build tool outranks a 7.5 flaw on an internet-facing login path, wasting effort. The critical band inflates until fixing criticals first stops discriminating, and an eight-month-old alert competes with yesterday’s. Five labels: CVE identifies, CVSS scores theoretical impact, NVD enriches, EPSS predicts likelihood, KEV confirms exploitation.
The working order is KEV first, then reachable high-EPSS items, then batched upgrades. This order matters because NIST has stopped enriching most CVEs, so unanalysed entries look benign. Snyk found 94 percent of 459 million findings had a fix while 10 percent were resolved. Queue structure is covered in why severity scores misorder risk.
How do you diagnose, fund and report a backlog that cannot be cleared?
Direct Answer
Measure inflow against closure on the items that matter rather than watching total ticket counts. If your team resolves confirmed exploits inside your window while low-signal findings accumulate, your queue is noisy; if actively exploited items age, your capacity is broken. That distinction decides whether you need intake filtering, more headcount or a remediation platform, and what you report upward: active exploit exposure, not raw volume.
Track four metrics: weekly inflow versus closure, ticket age percentiles, reachable items on KEV or high EPSS, and intake rejection rates. When third-party packages lack upstream fixes, record those exposures on an unpatchable register rather than forcing them into sprints.
Fund validation before discovery: scanning capacity is abundant, but internal review capacity is finite. HackerOne tracked submissions jumping 76 percent while remediation throughput rose only 19 percent. Prioritise contextual reachability and deduplication, and report active exploit exposure rather than raw volume, per diagnosing and funding a broken backlog.
Resource Hub: The AI Vulnerability Flood Deep Dives
Understanding the landscape
- Why vulnerability disclosure is outrunning everyone’s ability to patch: What counters and CNA policies measure, and where counts diverge from risk.
- What happens downstream when open source maintainers stop patching: The Glasswing funnel, maintainer limits, and verifying upstream dependencies.
Judging signal and speed
- AI slop in vulnerability reporting and how to tell real bugs from noise: Why automated submissions clog triage, and six checks for findings.
- Why the exploit window has collapsed and patch SLAs no longer hold: How weaponisation compressed to hours, and how to set policy on reachability.
Ordering, funding and reporting
- Why severity scores misorder risk and what to fix first instead: How to sequence KEV, EPSS and reachability around NVD enrichment delays.
- Diagnosing, funding and reporting a backlog that cannot be cleared: Separating noisy queues from broken capacity, and reporting residual risk.
Where to Start
Three situations, three starting points. If you must defend an expanding backlog count upward, start with turning the backlog into a risk register your board can act on. If you need to show what the numbers mean, start with the counters behind the headline, then how to order the queue. If 30-day compliance targets are under fire, jump to re-planning SLAs for an hours-long window. This cluster excludes legal liability, cyber insurance and implementation mechanics, focusing on engineering decisions that keep your business safe.
Frequently Asked Questions
Do I have to patch every CVE in my backlog?
No. Only a fraction of disclosed flaws ever create active danger, so patching everything spends scarce engineering hours on theoretical risk. Of the thousands of flaws disclosed each month in 2026, attackers exploited just 141. Patch confirmed exploitation first, then reachable high-likelihood items, then batch everything else into routine upgrade cycles.
What is the difference between a vulnerability, a CVE and an exploit?
A vulnerability is a weakness in code, a CVE is an identifier assigned to one, and an exploit is working code that abuses it. The three get conflated constantly, which inflates perceived risk. A CVE records that someone observed a flaw on a given date, nothing more. Exploitation is a separate event, and most identifiers never reach it.
Why does the same bug sometimes appear under several identifiers?
Identifier inflation. Some numbering authorities label nearly every bugfix, and separate projects can register the same underlying flaw independently. The Linux kernel now approaches 2,000 CVEs per release, up from roughly 500 in the 6.x era, because its authority labels almost everything. Deduplicate by root cause before treating a rising counter as rising risk.
Is open source software now less safe than commercial software?
No. Open source looks worse partly because its labelling is more thorough, not because its code is weaker. The Linux kernel’s CVE growth tracks a labelling policy change rather than a collapse in quality. The real upstream problem is absorption: Project Glasswing surfaced 1,596 findings across 281 projects by May 2026 and only 97 confirmed patches followed.
Can I trust a scanner finding that arrives without a proof of concept?
Not on its own. Demand a reproducible proof of concept before a finding consumes engineering time. Conversion data shows why: Anthropic’s 29,439 candidate bugs produced 516 upstream patches, under 2 percent. Quality is not the whole problem either, since 90.6 percent of independently assessed frontier findings proved genuine, but volume still overwhelms review.
Is EPSS a replacement for CVSS?
No. They answer different questions, and you need both. CVSS scores theoretical impact in isolation, while EPSS estimates the likelihood of exploitation in the next 30 days. Pairing them stops an unreachable 9.8 build-tool flaw outranking a reachable 7.5 login path that adversaries are actively probing.
Should I wait for a CVE to appear in CISA KEV before acting?
No. KEV confirms exploitation that has already happened, so waiting means waiting for evidence of an attack. Treat KEV as the top of your queue, not the gate to it. Reachable high-EPSS items warrant action before confirmation, using network isolation or virtual patching while the fix is prepared.
How do I know if a vulnerable library is actually reachable in my application?
You trace it at runtime, not in a spreadsheet. Software composition analysis tells you a package is present, while a call graph or runtime instrumentation tells you the vulnerable function actually executes. Most flagged components sit in unused paths, which is why reachability filters routinely clear the majority of high-severity tickets before anyone patches them.
What is virtual patching and when should I use it?
Virtual patching blocks exploitation of a known flaw without changing the vulnerable code, typically through a WAF rule, network policy or vendor signature. Use it when a fix does not exist yet, when the patch window is longer than the exploit window, or when the system cannot be restarted. It buys time, which is exactly what a collapsed exploit window removes.
Does my cloud provider or SaaS vendor absorb this risk for me?
Only partly. Providers patch the infrastructure layer, but you still own configuration, identity, integrations and the dependencies you deploy, container images included. A managed database patched upstream does not cover the vulnerable library sitting in your own application code. Confirm the split in writing rather than assuming it.
Will the AI vulnerability flood ease off on its own?
Unlikely. Discovery cost keeps falling as models improve, while verification, approval and release still run through human review. Nothing in the remediation path scales at the same rate. Expect inflow to keep rising and plan for throughput, because a strategy built on waiting for the wave to pass has no mechanism behind it.
