Where the 2026 CVE Increase Is Coming From

What this piece does

The 2026 CVE count is on track to nearly double for the second time since 2023. By the end of August the CVE Program's feed carried 57,429 records published in 2026 — already more than all of 2025 (48,154), on a monthly curve still climbing (11,814 in August alone). At that rate the year finishes near 95,000, at the top of the 70,000–100,000 range FIRST itself called "entirely possible".

The instinct is that software is falling apart. It isn't. Break the 2026 increase down by which organization issued each identifier and almost all of it traces to the industry expanding and refining how it discloses vulnerabilities — not to more or worse bugs. Two organizations, GitHub and VulnCheck, account between them for more than the whole year-over-year jump, mostly by giving open-source flaws an identifier they didn't have before. Several vendors — Oracle, Google, Microsoft among them — are each disclosing more completely, whether by moving to one record per fixed issue or by putting AI to work finding bugs earlier. The slice of all this that ever gets exploited is not growing at anything like the same rate.

The pattern across the three years is consistent: the count has grown for a different reason each time. 2024 was the Linux kernel adopting a CVE-for-nearly-every-fix policy. 2025 was the WordPress plugin research community. 2026 is GitHub and VulnCheck plus several vendors moving to finer-grained disclosure — while the 2024–25 drivers leveled off. A count that grows for a different reason each year is tracking the practice of disclosure — how thoroughly and how widely the industry documents its vulnerabilities — more closely than it tracks the state of software security.

On the data. This analysis runs on the CVE Program's canonical record set — the cvelistV5 repository that MITRE/CVE.org publish and that NVD, OpenCVE, and every commercial feed rebuild from — ingested and enriched by FlagThis (366,000+ published records). Per-CNA counts are that record set bucketed by assigning authority and publication date. Two checks back the numbers: a direct per-CNA diff against the cvelistV5 bulk repo every quarter from 2023 to 2026 finds zero missing records for Oracle, Microsoft, IBM, Apache, Cisco, and Adobe; and FlagThis's annual totals track the public NVD dataset within about 3% every year, matching the CVE Program's own published annual counts almost exactly. The vendor increases below are genuine upstream output, faithfully captured.

This post is the evidence, organization by organization. It also covers the part that is deliberate: vendors are disclosing more, and more precisely, partly because AI has compressed the time from a patch shipping to a working exploit — which raises the value of clear, complete advisories for everyone downstream.

A note on what this is and isn't: this is our reading of public data and public statements, not the last word. The per-vendor attributions in particular involve some pattern-reading, the numbers shift every month, and FlagThis can get things wrong. We've tried to hedge accordingly, and we'll update the piece as better information comes in — corrections welcome.

The acceleration is steeper than anyone forecast

FIRST, which runs a time-series model on the disclosure feed, revised its 2026 forecast upward through the year: its February projection was ~59,000 CVEs; by its June mid-year update it was 66,000, with disclosures running 46% above the February model. FlagThis's month-by-month data suggests even the revised number is low — the publication rate climbed from ~4,300 in January to ~7,950 in June to ~11,800 in August, a smooth monotonic ramp rather than a single backfill spike. FIRST attributes the increase to "changes in how flaws are found and reported," not deteriorating code quality — a reading Trend Micro's research team echoed in a piece titled "Volume Is Not Risk."

One caveat up front: "CVE" and "vulnerability" are not the same unit. FlagThis holds about 18,000 rejected CVE records on top of the 366,000 published ones; roughly 3.6% of 2025's assignments were later withdrawn. The vendor and product strings the catalog carries are noisy, so any per-vendor count is approximate. The figures below are directional, and the direction is what matters.

The increase, decoded: two organizations account for most of it

CVE IDs are handed out by CVE Numbering Authorities (CNAs) — the vendors, open-source projects, bug-bounty platforms, and research shops the CVE program authorizes to assign identifiers from their own block. The program's directory now lists 542 of them (417 vendors, 42 research labs, 29 open-source projects, 21 national CERTs, 13 bug-bounty platforms, and a handful of others) — up from about 350 when curl joined in 2024. Around 365 assigned at least one CVE in 2025. That growth in participation is itself part of the story.

Break FlagThis's 2026 records down by which CNA issued them, and the increase resolves into a handful of specific, mostly deliberate changes:

The two rows at the top do most of the work. In the first eight months of 2026, GitHub and VulnCheck issued about 14,600 CVEs between them — nearly four times their combined total for all of 2025 (~3,900). That increase, roughly 10,600, is larger than the amount by which 2026's eight-month total already exceeds all of 2025 (~9,300). Both figures compare eight months of 2026 to twelve of 2025, so if anything they understate the shift. Every other high-volume cataloger — Linux, VulDB, Patchstack, MITRE, Wordfence — is level or lower. The vendor rows lower in the table (Chrome, Oracle, Microsoft, and behind them Red Hat and Apache) each have their own explanation, and the next section walks through them.

Neither of the top two is "more bugs shipped in 2026." VulnCheck is doing catch-up work — FIRST reports a 3,119% year-over-year jump in its activity, and about a third of its 2026 records carry a CVE ID from 2024 or earlier: genuine older flaws that never got an identifier, now getting one. (That third is a floor — a CNA cataloging a 2021 bug today often assigns it a current-year ID, so it looks fresh. Feed-wide, at least 13% of 2026 records are this kind of retroactive assignment.) GitHub does very little of that — about 3% — and is instead absorbing a fast-growing stream of open-source vulnerability reports and issuing the CVE ID itself. Its engineering team has written openly about the intake: private vulnerability reports went from ~550/week in January to ~3,000/week by May 2026, and its CNA CVE requests roughly 10x year over year — briefly outpacing its own publication capacity. The reports are real and mostly newly filed; what changed is that GitHub now systematically turns them into CVE records.

This is a broadening of who gets an identifier — open-source flaws that used to go unrecorded now get one — and a good development for anyone tracking supply-chain risk. Alongside the legitimate reports, projects are also seeing more low-value automated and AI-generated submissions, and maintainers are building new filters for them; that work is covered further below.

The lower-volume end of the table reflects the CNA model maturing. MITRE now assigns roughly half what it did in 2024 because more organizations have taken on ID assignment for their own products — the system working as designed. And the WordPress plugin research wave that led 2024–2025 (Patchstack and Wordfence together assigned over 10,000 CVEs in 2025, about a fifth of the year) has leveled off. A 2025 year-in-review that expected WordPress to keep driving the numbers would be looking at last year's pattern.

What each vendor's rising count reflects

FlagThis's CVE analysis dashboard surfaces vendors whose recent CVE rate is well above their own multi-year baseline — as of late August 2026, Oracle, Apache, Google/Chrome, Microsoft, and IBM. (The "standard deviations above baseline" it shows is a sort order, not a calibrated statistic — CVE counts are bursty and batch-driven — and it reflects publication rate, not who found a bug or why.) Reading the public record for each, the through-line is a security or disclosure program doing more. We may be missing context on some of these; where a vendor has explained its own numbers, we lean on that.

Oracle: one record per fixed issue

From 2023 through early 2026, Oracle assigned roughly 290–370 CVEs a year for its own products — a batch each quarter with its Critical Patch Update. (An Oracle quarterly update "addresses" more CVEs than Oracle itself assigns; the October 2023 update covered 176, most of them in bundled third-party components — OpenSSL, Apache libraries — that keep their upstream CVE IDs and are counted under those projects.)

With the July 21, 2026 update, Oracle began issuing a discrete CVE for far more of the individual issues in each update. It assigned 1,097 CVEs in one day, across 263 products, and 889 more in August — all CVE-2026- identifiers for Oracle's own code, with (in the batch we examined) essentially none referencing a bundled library. Oracle's quarterly patch scope looks consistent with prior years; what changed is that sub-component fixes, defense-in-depth hardening, and static-analysis findings that earlier updates shipped without a dedicated identifier now each get one. It is the same direction the Linux kernel took in 2024 — moving toward documenting each fixed issue individually.

For a defender, Oracle's 2026 count — 2,442 in eight months against about 1,400 across all of 2022–2025 — reads best as a more granular disclosure practice: more traceability per advisory, rather than a change in how much Oracle is fixing.

Google: a CVE for a larger share of Chrome fixes

Google's browser CVE assignments went 261 in 2024, 195 in 2025, and about 2,470 in the first eight months of 2026. Three mid-2026 Chrome releases fixed 1,442 flaws — more than the previous 23 milestones combined, with 349 of the 370 in Chrome 151 credited to Google's own security work. The same reporting notes Google is "working on automating efforts to generate release notes and CVE descriptions"; historically Chrome did not assign a CVE to every fixed bug, and it now does so for a much larger share — mechanically similar to the Linux kernel's 2024 move. The mix now includes more of the lower-severity issues that in earlier years were fixed without a dedicated CVE — the average CVSS moved from 7.6 to 7.0 — which means more of Chrome's routine security maintenance is visible in the public record. The high-severity work continues alongside it: a critical Navigation-component sandbox escape (CVE-2026-3545) and an actively-exploited V8 flaw (CVE-2026-11645) both landed in this period.

Microsoft: an AI program finding bugs earlier

Microsoft's increase appears to have a different source — more bugs found. Its CNA output ran ~100–180 a month through mid-2026, then rose to 648 in July and 471 in August — a record Patch Tuesday — with its advisories reading much as before, just more of them.

Microsoft attributes this to an internal system it calls MDASH, a "multi-model agentic scanning harness" — 100+ AI agents run by its Autonomous Code Security team, which it reports hit 96% recall against five years of confirmed Windows vulnerabilities in one component. On July 9, 2026 Microsoft told customers to expect "a higher volume of security updates in each security release" as AI helps it find more issues, framing the increase as "evidence that defenders are getting better." The July and August numbers are the first two Patch Tuesdays after that statement. From outside we can't fully separate the MDASH contribution from a heavier patch month, but the vendor's account and the shape of the data point the same way: bugs found and fixed earlier because of AI — a rising count that reflects a security program investing ahead of the threat.

Red Hat, Apache, IBM, VMware

The others on the panel each have a plausible, benign explanation. Red Hat (300 in 2025 → 769 in eight months of 2026) ramped steadily from March with its usual long, well-formed advisories — consistent with more thorough component-level triage across its large package portfolio. Apache (218 → 699) reflects mostly more external research — CVEs it credits to named human researchers roughly tripled, concentrated on its high-traffic projects. IBM (606 → 836) is about a quarter retroactive. VMware, now part of Broadcom, went from 66 to 275, disclosed in periodic batches. All reconcile against the CVE program's own data; Cisco and Adobe, roughly level, serve as a check that this isn't a FlagThis-side effect.

The common thread: a vendor's count can rise for a new research program, a bug-bounty, an audit, finer-grained disclosure, an AI discovery program, or catch-up work — and from outside it's often hard to be certain which. In each 2026 case we looked at, the explanation is a security or disclosure effort doing more, not code getting worse.

The Microsoft and Apple rows together make a broader point worth holding onto: a CVE count can move in either direction for good reasons. Microsoft's went up because an AI program is surfacing real bugs. Apple's went down — 730 in 2025 to 561 in eight months of 2026 — over a period in which it shipped Memory Integrity Enforcement on its A19 silicon, a hardware defence aimed at making whole classes of memory-corruption bug unexploitable rather than at cataloguing each one. One is surfacing more bugs; the other is reducing the payoff of finding them. Both are serious security work, and neither is legible from the direction its count moved.

Two drivers already well covered

The Linux kernel became a CNA in February 2024 and now assigns a CVE to nearly every fix with a plausible security dimension — 289 kernel CVEs in 2023, 5,686 in 2025, of which Mondoo's analysis counts one as exploited in the wild. (Kernel exploitation is overwhelmingly local privilege escalation, which KEV and public-exploit telemetry both under-count, so that figure is likely a floor — but comprehensive disclosure and operational risk are still different measures.) A vendor:linux kev:true filter in FlagThis's query language narrows the full kernel record set to the entries with tracked real-world exploitation. The WordPress plugin research community, via Patchstack and Wordfence, led the 2024–2025 numbers — over 10,000 CVEs in 2025, about a fifth of the year — and has since leveled off.

Enrichment became a shared effort. The U.S. National Vulnerability Database has long added the structured metadata scanners rely on — severity scores, machine-readable product identifiers (CPE), weakness-type codes. Under record volume, NIST moved NVD to a triage enrichment model in April 2026, prioritizing CVEs in CISA's KEV catalog, federal software, and "critical software." About 58% of 2025 CVEs got a CPE, so tools that rely only on NVD's product mappings will want to also pull the CNA's own affected data or CISA's enrichment. CISA's Vulnrichment program has taken up much of the slack — adding severity, a weakness type, and an SSVC priority to a secondary block of the record on around 90% of recent CVEs. Enrichment is now several publishers contributing to one record — more resilient than a single pipeline, and worth pulling from more than one source.

AI's contribution is still small — and growing

The genuinely new input is AI-assisted bug-finding, and its scale is easy to overstate. Google's Big Sleep found CVE-2025-6965, a SQLite memory-corruption bug, and — per Google — helped get it fixed before in-the-wild exploitation began, which Google described as a first for an AI agent. Anthropic's Project Glasswing has run its Claude "Mythos" model across open-source projects at scale — its disclosure dashboard shows 177 CVEs and 285 GitHub advisories assigned as of late August 2026, and FIRST attributes a 164% first-quarter rise in Mozilla's disclosures to that work.

It helps to separate three things. Autonomous agents finding and reporting a bug end to end are still rare — FlagThis's credit classifier positively attributes 21 published CVEs to an autonomous AI agent (17 to Big Sleep), and Anthropic's own count is a few hundred. AI-assisted human research — an LLM helping write a fuzz harness or a proof of concept — is already common and folded into the GitHub and bug-bounty intake, but those researchers credit themselves, so no classifier separates it out. And AI-assisted vendor programs like Microsoft's MDASH are new — MDASH is the first we can see clearly in the numbers, on the order of a thousand additional Microsoft CVEs on this year's pace, credited internally like any other find. Autonomously-attributed CVEs remain a small share of a year-over-year increase above 40,000; the assisted kinds are larger and mostly invisible to any measure that keys on who gets the credit, so our figures here are best read as lower bounds.

What makes AI the input to watch is its trajectory. On July 28, 2026 the CVE Program launched a six-month pilot letting Anthropic and OpenAI assign CVE IDs directly for bugs their models find in third-party software. FIRST's assessment is that the constraint has already shifted from discovery to human triage — once a single scanning campaign can produce hundreds of validated findings, annual volume depends on how fast people can verify and coordinate disclosure, not on how many bugs exist.

Signal and noise

Not every automated submission is useful, and open-source maintainers have been candid about the load. The curl project's Daniel Stenberg has written about the volume of AI-generated reports — confident, plausible-sounding write-ups describing code that isn't there — and curl restructured how it accepts reports in February 2026 in response. These don't become CVEs; maintainers filter them out. But the filtering costs time, and triage capacity is what the whole system runs on. Better tooling for separating signal from noise is an active area of work across the ecosystem, and it's a fair reason to treat any single-month volume figure with some caution.

A more distributed, more resilient system

In April 2025, a funding gap in the contract behind MITRE's operation of the CVE program was resolved close to the deadline, with CISA extending the agreement. Partly in response, ENISA launched the EU Vulnerability Database and became a formal CVE Root, able to recruit its own CNAs. The result is a more distributed system — multiple roots, more participating organizations — which is more resilient overall, even if it also means some overlap between catalogs to reconcile.

Rain vs flood: the actionable slice is roughly flat

FIRST frames this with a weather metaphor. The rain is total disclosure volume — the 95,000-and-climbing. The flood is the subset of vulnerabilities with a realistic chance of being used against you. The flood does not appear to be rising with the rain — filter the volume for a CISA KEV listing or an EPSS score above 10%, and per FIRST the actionable set comes out roughly flat relative to the increase. Not unchanged — it grew — but well short of the ~40%-a-year pace of the raw count.

The proportions: the Cyentia/FIRST EPSS study, across ~238,000 CVEs, found that about 6% of published vulnerabilities are ever observed exploited in the wild — a cumulative figure over the catalog's whole history; the share of any single year's crop exploited within that year is more like 1–2%, which cuts the same way. Confirmed exploitation as tracked by government is smaller still — CISA added 245 vulnerabilities to its KEV catalog in 2025, about 0.5% of the year, taking the catalog to ~1,484 total.

Both signals have blind spots worth naming. EPSS is a prediction model, not an exploitation sensor — it scores the likelihood of attack from features like public exploit code and chatter, so a wave of quietly-disclosed CVEs with no exploit will always score near zero; the "flat EPSS-above-10%" finding partly reflects the model behaving as designed. And KEV is a US federal remediation-enforcement list, weighted toward internet-facing, ransomware-driven exploitation; it under-counts targeted espionage, browser and mobile exploit chains, and local privilege escalation. The conclusion survives the caveats — two independent signals, one predictive and one human-curated, both stay roughly flat while the raw count nearly doubles, and FlagThis's own numbers (about 9% of its 366,000+ CVEs carry any public exploit or PoC, ~1,700 carry a KEV listing) sit in the same range — but "flat" is a directional claim, not a precise one.

So a doubling in the count since 2023 does not appear to mean the patch queue doubled. It looks more like the record set becoming more complete, more distributed, and more inclusive of bundled and lower-severity issues — while the number of vulnerabilities that matter operationally grew much more slowly.

Why the industry is disclosing more

A rising number is easy to read as a warning sign. It's better read as the industry getting more organized about disclosure — and there are good reasons that's happening now.

The direction of travel is toward complete, prompt, machine-readable disclosure. CISA's Secure by Design pledge, signed by roughly 370 software makers, sets a target of issuing a CVE in a timely manner for every critical- or high-severity vulnerability that needs a customer to act — internally-found ones included — with the CWE and CPE fields filled in. The pledge treats complete, timely CVEs as the standard to aim for. A vendor moving from "this release contains security fixes" to a categorized CVE per issue generates more records, and also hands defenders the structured data they need to prioritize. Microsoft has framed its own increase this way: as its AI tooling finds more bugs, "customers will see a higher volume of security updates included in each security release." For Microsoft, at least, the count going up is by design.

The timing tracks a real shift in the threat. The same model capability that is starting to find bugs is further along at building exploits from them. Anthropic's red team reports its Mythos model producing working proof-of-concept exploits from patch diffs in as little as 31 minutes, including for some Windows kernel bugs rated "Exploitation Unlikely" (a rating calibrated for human researchers). CrowdStrike observed 88% of proof-of-concept-backed exploitation in the first half of 2026 happening within 48 hours of the PoC becoming public. If the gap between a patch shipping and an exploit existing is shrinking toward hours, precise disclosure becomes more valuable for everyone downstream.

For an organization that ships software of its own, a few things follow — offered as suggestions, not a checklist:

• Consider getting ahead of your own CVE backlog. Old, thinly-described vulnerabilities in your products are a natural first target for automated patch analysis. Assigning and documenting them on your own schedule looks increasingly like a defensive step, in the same spirit as the Linux kernel's and Oracle's moves toward per-issue records.
• Prioritize by exploitability where you can — KEV and high-EPSS items first, then the rest on your normal cadence — since "we have weeks" is a less safe assumption than it was for anything that ships with public exploit code.
• Lean toward complete advisories over minimal ones. Full CVE records — CWE, CPE, version ranges, fix availability — help a customer deploy your fix quickly rather than spend days triaging it. Clear disclosure is increasingly part of how customers evaluate a vendor's security maturity.

We could be wrong about the balance here for any given vendor, and we'd welcome correction from teams closer to the details.

What this might mean for your program

The standard advice — prioritize with EPSS and KEV — still holds. A few things that seem specific to an increase that mostly reflects broader disclosure rather than broader risk:

• Vulnerability-management leads: deploying vendor bundles (a Chrome update, an Oracle quarterly update) on your normal cadence is probably still the right call — patches ship as bundles, and the small share that matters most rides in with the rest. It's worth being cautious about turning a vendor's identifier-count spike into an emergency-ticket scramble; checking whether that vendor changed its disclosure granularity, and how much of the advisory is bundled third-party components you already track, may save a lot of churn. On FlagThis, a filter like vendor:oracle kev:true or vendor:oracle epss>=0.5 narrows a large-volume year to the entries most likely to need their own workflow.
• Detection engineers: KEV and EPSS came through the increase intact and remain solid to build on. The place to watch is product-identifier coverage — with a meaningful share of recent CVEs missing a CPE, asset-matching that relies only on NVD CPE strings may miss real exposure. Pulling the CNA's own affected data and CISA's enrichment from the CVE 5.x record, or adding a commercial feed, helps close that gap.
• Anyone presenting the count to leadership: the CVE count is, roughly, a measure of how much attention and tooling the industry is putting into finding and documenting its own flaws. That's a reasonable read of it, and a weak proxy for how exposed a particular organization is.

What 2027 might look like

Forecasting this is hard — FIRST's own February model (~51,000 CVEs for 2027) was overtaken within months — so treat any number, ours included, as a rough floor. A few things seem likely to shape where 2027 lands: whether GitHub's and VulnCheck's catch-up work tapers or settles into a higher baseline (GitHub's publication backlog suggests there is still more to come); whether AI-assisted discovery scales further, with the Anthropic/OpenAI CNA pilot up for renewal in January 2027 and other vendors potentially following Microsoft's MDASH lead; and whether more vulnerability work shifts toward package-ecosystem advisories (OSV, GHSA) and machine-readable exploitability statements (VEX) alongside the CVE record. Our best guess is that the number keeps climbing and stays a better measure of disclosure effort than of risk — but the useful work remains on the small share that gets exploited.

Timeline

The bottom line

Our reading of the 2026 data is that the CVE curve is climbing because the industry is disclosing more — not because the software under it is getting worse. Broken down by who issues each identifier: VulnCheck is giving older un-numbered flaws an ID, and GitHub is systematically turning a fast-growing stream of open-source reports into CVE records; together they account for most of the year-over-year increase, while MITRE and the WordPress research community have leveled off. Among individual vendors, Oracle, Google, and the Linux kernel are each documenting more of their security work in the public record. Microsoft's increase comes from an internal AI program finding bugs earlier. And Apple's count fell over the same period as it shipped a hardware defence aimed at whole classes of memory-corruption bug. The count moved in different directions for several serious security efforts — which is the clearest sign that it isn't, on its own, a measure of how secure anything is.

What has not changed much is the part that should drive a defender's day. Roughly 6% of published CVEs are ever exploited in the wild; about half a percent land in CISA's KEV catalog in a given year. Those slices are not keeping pace with the raw count. The number on the chart is, more than anything, a measure of how hard the industry is now looking at — and documenting — its own code, which is a good thing. The place it does seem to call for action is a vendor's own products, where a shrinking patch-to-exploit window makes it worth getting ahead of your CVE backlog and disclosing clearly.

We may have some of this wrong — the per-vendor attributions especially rely on public statements and pattern-reading, and the underlying numbers move every month. This is a maintained page: the breakdown is re-run on each update, the revision history below tracks what changed, and we welcome corrections and additional context from anyone closer to the details (about page has contact information).

Common questions

How many CVEs will there be in 2026? On the current run rate, about 95,000 — up from 48,154 in 2025. The CVE Program's feed already held 57,429 records published in the first eight months of the year.

Why is the CVE count rising so fast? Our reading is that it's mostly about how identifiers get assigned and by whom, not about more or worse vulnerabilities. In 2026 the growth is concentrated in two organizations — GitHub (giving a fast-growing stream of open-source reports a CVE ID) and VulnCheck (assigning IDs to older flaws that never had one) — plus several vendors, including Oracle and Google, now issuing a CVE for more of the fixes they ship. The high-volume assigners that led 2024 and 2025 (the Linux kernel, WordPress plugin research) have leveled off.

Does the CVE increase mean software is less secure? We don't think so. The share of published CVEs ever exploited in the wild (~6%) and the share that lands in CISA's KEV catalog (about half a percent a year) are not growing at the rate the raw count is. The count appears to have decoupled from operational risk.

Can a rising CVE count be a good sign? Often, yes. Microsoft's count roughly doubled in mid-2026, which it attributes to an internal AI program (MDASH) finding and disclosing real bugs. Apple's count fell over the same period as it shipped a hardware defence aimed at making most memory-corruption bugs unexploitable. Both look like significant security investments; the count alone doesn't tell you which is happening.

Should the increase change my patch SLAs? For third-party software, probably not — prioritizing by CISA KEV and EPSS and deploying vendor bundles on your normal cadence is likely still right. The consideration is different for software you ship yourself: with the patch-to-exploit window shrinking, there's more value in getting ahead of your own CVE backlog and disclosing clearly.

Sources

• The 2026 Vulnerability Forecast Update: Navigating the AI Epoch — FIRST
• FIRST Mid-Year Vulnerability Forecast press release — FIRST
• FIRST Releases 2026 Vulnerability Report (February) — FIRST
• FIRST Forecasts Record-Breaking 50,000+ CVEs in 2026 — Infosecurity Magazine
• Volume Is Not Risk: Making Sense of the 'Vulnpocalypse' — Trend Micro
• 2025 CVE Data Review — JerryGamblin.com
• CVE Volume Surges Past 48,000 in 2025 as WordPress Plugin Ecosystem Drives Growth — Socket
• Inside the Advisory Database and what happens when vulnerability volume breaks records — GitHub
• A Visual Exploration of Exploitation in the Wild — Cyentia Institute / FIRST
• CISA KEV Catalog Expanded 20% in 2025, Topping 1,480 Entries — SecurityWeek
• 2026 State of Vulnerabilities — Mondoo
• The Linux Kernel CVE Flood Continues Unabated in 2025 — TuxCare
• How the CNA thing is working out — daniel.haxx.se
• CVE Numbering Authorities (CNAs) — CVE Program
• Oracle October 2023 Critical Patch Update Addresses 176 CVEs — Tenable
• Oracle's July 2026 update fixes ten 10.0 vulnerabilities in Fusion Middleware — CSO Online
• Google AI "Big Sleep" Stops Exploitation of Critical SQLite Vulnerability — The Hacker News
• Google's AI Tool Big Sleep Finds Zero-Day in SQLite — The Hacker News
• Google's latest AI security announcements (Big Sleep, summer 2025) — Google
• Three Recent Chrome Releases Fix 1,442 Flaws, More Than Prior 23 Updates Combined — The Hacker News
• Defense at AI speed: Microsoft's multi-model agentic security system (MDASH) — Microsoft Security
• Microsoft's MDASH AI System Finds 16 Windows Flaws Fixed in Patch Tuesday — The Hacker News
• Evolving Windows vulnerability management to meet the speed of AI-powered discovery — Windows Experience Blog
• Microsoft Patches a Record 570 Security Flaws — Krebs on Security
• Memory Integrity Enforcement: A complete vision for memory safety in Apple devices — Apple Security Research
• Anthropic coordinated vulnerability disclosure dashboard — Anthropic
• Anthropic Project Glasswing update (May 2026) — Help Net Security
• CVE Program Launches Frontier AI Researcher CNA Pilot — CVE Program
• The New Stack — Daniel Stenberg on AI-generated vulnerability reports to the curl project
• Funding Expires for Key Cyber Vulnerability Database — Krebs on Security
• MITRE CVE program regains funding as renewal deal reached — Cybersecurity Dive
• NIST Limits CVE Enrichment After 263% Surge in Vulnerability Submissions — The Hacker News
• NIST Updates NVD Operations to Address Record CVE Growth — NIST
• EU launches a European Vulnerability Database to boost its digital security — European Commission
• Secure by Design Pledge — CISA
• Microsoft expects more Windows security updates from AI-discovered flaws — BleepingComputer
• Measuring LLMs' impact on N-day exploits — Anthropic
• CrowdStrike 2026 Threat Hunting Report: Exploitation Window Closes as AI Use Accelerates — CrowdStrike
• CVE List V5 — the CVE Program's canonical record repository (GitHub)
• NVD CVE API v2.0 — NIST
• FlagThis CVE analysis dashboard
• FlagThis CVE filter language reference