CVE Statistics: Volume, Severity, and Exploitation

The problem with CVE statistics is not the rising count. It is pretending publication volume measures the risk inside your environment.

CVE statistics tell you how much public vulnerability data the ecosystem is producing. They do not tell you how many affected products you run, which attack paths are reachable, what attackers use, or whether repairs worked. A board chart that shows 48,244 CVEs without those denominators is a news graphic, not a management system.

Ask how global volume changes local work. Measure the narrowing path from published records to applicable products, installed versions, exposed paths, exploit evidence, owned repairs, and closure proof. Every percentage needs a named numerator, denominator, source date, and operational decision.

What do current CVE statistics show?

The CVE Program's official metrics show 40,077 published CVE Records in 2024 and 48,244 in 2025. That is an increase of 8,167 records, or about 20.4 percent. The same CVE Program metrics snapshot records 35,872 publications in the first two quarters of 2026. Q2 alone produced 20,709, about 37 percent more than Q1.

Those are publication counts, not a count of unique software products and not a count of local findings. One product can receive many CVEs. One CVE can affect thousands of assets. A rejected record can change a historical quarter while the current year is still open. The CVE Program says it reconciles annual totals at year end and does not recalculate prior years after a new year begins.

The identifier year is another trap. CVE-2025-12345 tells you when the ID block was assigned, not necessarily when the record was published, exploited, or fixed. Trend work should use an explicit date field. Mixing CVE ID year with publication date can move records between periods and create a growth story that is only a query bug.

Build the source table so another analyst can reproduce it. Record the API endpoint, query time, time zone, included record states, and date field. Keep rejected records outside the published denominator, but retain them in the snapshot so later revisions have an audit trail. A live dashboard without a frozen source extract can change after the board has seen it, leaving the security team unable to explain why.

Show absolute change beside percentage change. The move from 40,077 to 48,244 is 8,167 additional records and a 20.4 percent increase. The first number helps estimate ingestion work. The second supports comparison across periods. Neither measures exposed assets. Label partial years as partial years, and do not turn six months of publication data into a full year forecast unless the method and uncertainty are visible.

Why did NIST change NVD enrichment in 2026?

Publication growth has downstream cost. On April 15, 2026, NIST changed how the National Vulnerability Database schedules enrichment. Its NVD operations update says CVE submissions increased 263 percent between 2020 and 2025. Submissions in the first three months of 2026 were nearly one third higher than the same period in 2025.

NIST also reported enriching nearly 42,000 CVEs in 2025, 45 percent more than any prior year, yet the work still did not keep pace. The new model prioritizes KEV entries, software used by the federal government, and critical software. Other records remain in NVD but may be marked as lowest priority and not scheduled for immediate enrichment.

This is the most important development in the last year for anyone reporting CVE trends. A missing NVD score, CPE, or weakness mapping no longer means the record is unimportant or invalid. It may reflect scheduling. Report enrichment coverage separately from vulnerability volume, and preserve CNA or vendor data when NVD has not added its own analysis.

What does rising CVE volume actually mean?

More records can mean more flaws are being found. It can also mean more vendors publish directly, more projects have become CNAs, assignment rules changed, automated discovery improved, or a large project altered its disclosure practice. The count reflects the production system as much as the security of software.

The CVE Program reports that 94 percent of 2026 records came from CNAs outside the CNAs of Last Resort, compared with 50 percent in 2017. Decentralized publication is doing what it was built to do. A higher count can be a sign of better disclosure coverage, even while it creates more work for every consumer downstream.

Do not compare products by raw CVE count without normalizing for product size, deployment model, research attention, disclosure policy, supported versions, and time in market. A project that assigns and fixes records openly can look worse than a product with weak disclosure. Silence is not safety.

How many CVEs are actually exploited?

No public catalog can prove the full universe of exploitation. CISA KEV answers a narrower and more defensible question: which CVEs meet CISA's evidence threshold for known exploitation. The KEV JSON feed released August 27, 2026 contains 1,685 records. CISA added 201 during 2026 through that date. Of those additions, 123 carry a 2026 CVE ID and 78 carry an earlier identifier.

In other words, about 39 percent of the records added to KEV in 2026 did not have a 2026 identifier. That does not prove when exploitation began. It proves that a “new CVEs only” watchlist misses important priority changes in old records. Track KEV addition date independently from CVE publication and identifier year.

Breach data confirms why exploit evidence deserves its own metric. The May 2026 Verizon Data Breach Investigations Report found vulnerability exploitation was the most common initial access vector at 31 percent of breaches in its reporting dataset. Yet only 26 percent of critical vulnerabilities, defined there as KEV entries, were fully remediated by organizations in 2025. Median full resolution time rose to 43 days.

Severity still matters, but it answers a different question. CVSS estimates technical impact and exploit conditions. KEV records observed exploitation. EPSS estimates near term exploitation probability. Local context tells you whether the affected component exists, is reachable, and supports a material process. A useful priority decision combines them instead of asking one score to do every job.

What does CVE growth do to analyst capacity?

The first half of 2026 produced 35,872 records across 181 days, close to 198 records per day. At eight minutes of review per record, blind global triage would consume about 1,584 minutes, or 26.4 analyst hours every day. That is more than three full time people before the team inspects one asset.

Reading faster is not the answer. Filter earlier. Map records to an owned product catalog, then to observed versions and exposure. If only 2 percent of those daily records match a product in the estate, the queue falls from 198 to about 4. The saved capacity belongs in validation, remediation, and investigation.

This math should appear in planning. A feed license that adds 50 daily alerts at ten minutes each creates more than 166 analyst hours across 20 workdays. If it confirms one exposed KEV entry that another source missed, that cost may be justified. If it repeats existing aliases, it is paid duplication.

Which CVE metrics should a security dashboard show?

Separate supply, coverage, threat, execution, and proof. Mixing them into one backlog number makes cause and action impossible to see.

Put the denominator beside every percentage. “Ninety percent patched” is meaningless if the denominator excludes unmanaged assets or counts tickets instead of vulnerable instances. “180 of 200 confirmed affected assets now show a fixed version” is a metric an operator can challenge and an executive can act on.

How do you produce defensible CVE statistics?

1. Choose the date field and snapshot time before running the query.
2. Count records, assets, findings, and repairs as separate units.
3. Preserve source, record state, revision time, and enrichment status.
4. Join public records to owned products and observed system state.
5. Publish numerators, denominators, exclusions, and the decision each metric drives.

Keep a frozen monthly snapshot even if the source is live. That lets the team reproduce a board number after a CVE is rejected, a score changes, or an affected range is corrected. The current truth belongs in operations. The historical snapshot belongs in reporting. You need both.

Link every trend to action. Rising unmatched records may require better product normalization. Falling closure quality may require verification from endpoint state. Growing KEV age may expose an ownership failure. Our vulnerability prioritization guide shows how to turn those signals into a queue that has business context and accountable owners.

Which CVE statistics should the board ignore?

Drop the unqualified backlog total. It rewards teams for deleting records and punishes teams that improve discovery. Replace it with confirmed exposed assets by business service, oldest unresolved KEV exposure, repair capacity, and the share of completed work that passed validation. Those measures reveal control and delay.

Avoid average CVSS as a trend. A shift in source coverage or scoring versions can move the average without any change in local risk. If severity distribution is reported, show which scorer, which CVSS version, how conflicts were resolved, and how many applicable records had no score.

Do not celebrate ticket closure alone. A ticket can close because an asset vanished from inventory, an owner accepted risk, or a change was scheduled. Report the reason and separate closure from verified repair. The board needs to know whether exposure fell, not whether workflow objects changed state.

Frequently asked questions about CVE statistics

How many CVEs were published in 2025?

The CVE Program reports 48,244 published records for 2025 after annual reconciliation. That was about 20.4 percent more than the 40,077 records reported for 2024.

Why do CVE totals differ between websites?

Sites may use CVE ID year, publication date, NVD publication date, different time zones, live revisions, or different rejected record handling. Check the date field, snapshot time, and record states before comparing.

Does a high CVE count mean a product is insecure?

Not by itself. Normalize for product size, research attention, disclosure behavior, supported versions, severity, exploitation, and your deployed exposure. Open reporting can raise the count while improving security response.

Which vulnerability statistic matters most?

For operations, verified closure of confirmed exposure matters most. Global publication, CVSS, KEV, and EPSS are inputs. The outcome is whether a reachable risk on an owned asset was removed and rechecked.

The executive takeaway

Rebuild the vulnerability dashboard around a funnel, not a global count. Show published supply, local matches, confirmed exposure, exploit evidence, owned repairs, and verified closure with explicit denominators. Deep endpoint context with AI driven analysis can reduce the distance between those layers. Start by fixing one metric this week: replace “open CVEs” with “confirmed exposed assets awaiting verified repair.”