CVE publication trends

47,802 CVE records were published in 2025, up 20% on the year before. 2026 has already reached 85,338 with months still to run.

Volume has grown every year since the CVE Program began, but the rate of growth changed sharply in 2026. Use the chart above to see the trend by month, quarter or year.

On this page. The chart and figures above are CVE statistics rebuilt daily from the CVE Program's cvelistV5 repository, the same source the CVE Program publishes from.

They cover publication volume by CVSS severity, by assigning organization and by week, month, quarter or year, along with the most recent critical records. For a single vulnerability's detail, follow any identifier through to cve.org.

Three things are happening at once, and the published record cannot separate them.

More organizations can now assign CVE IDs, so vulnerabilities that were previously never registered are being recorded. Automated and AI-assisted vulnerability discovery has raised how much any one researcher can find. And CISA's enrichment programme has back-filled detail on older records, which changes historical figures after the fact.

Rising CVE counts are therefore not by themselves evidence that software is getting less secure.

A CNA is an organization authorized to assign CVE IDs and publish records within its own scope, usually its own products. 491 CNAs appear in this dataset.

Vendors, open-source projects, bug-bounty platforms and national CERTs all act as CNAs. The largest here is mitre, with 39,501 records. Because a single CNA changing its process can move the totals noticeably, the chart lets you filter to one organization at a time.

CVSS scores a vulnerability from 0.0 to 10.0 and groups it into bands: Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9) and Critical (9.0-10.0).

The score describes intrinsic technical characteristics such as how the vulnerability is reached and what it compromises. It is not a measure of how much any particular organization is at risk.

18.0% of the records published since 2020 carry no CVSS score in either the CNA's own data or CISA's enrichment.

Scoring was not required for most of the CVE Program's history. Coverage improves steeply from 2023 onward and is now near-universal, so the shrinking Unknown band on the chart reflects a change in reporting practice, not a change in the vulnerabilities themselves. Any analysis that ignores unscored records will understate older years.

A vulnerability is a flaw in software. A CVE is a public identifier assigned to a specific, disclosed instance of one.

Most vulnerabilities never receive a CVE: they are found and fixed internally, or they fall outside any CNA's scope. CVE counts therefore measure disclosure activity, not the true quantity of flaws in existence.

Every figure is built from the CVE Program's official cvelistV5 repository, using the snapshot taken on Oct 24, 2026 UTC.

Records are counted by publication date rather than by the year in the CVE ID, since roughly a fifth of records are published in a different year to the one their identifier names. Rejected and withdrawn records are excluded.

Not on its own. A Critical vulnerability in a component you ship but never call may be less urgent than a Medium one on your public API.

Real prioritization needs to know whether the affected component is present in your software, whether the vulnerable code is reachable, and whether the vulnerability is being exploited. CVSS answers none of those.

The CRA requires manufacturers to handle vulnerabilities across a product's supported lifetime, report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware, and keep technical documentation current.

Those duties scale with the volume in this chart. Triaging tens of thousands of new records a year against your own software is not realistic manually, which is why the CRA effectively assumes an SBOM and an automated matching process.

You need an accurate inventory of what your software contains, then continuous matching of that inventory against the CVE feed.

CRACI generates an SBOM from your build, matches it against new CVE records as they are published, and shows only the advisories that reach code you actually ship — along with the documentation the CRA expects you to keep.

See how vulnerability tracking works in practice.