Vulnerability Statistics 2026: CVEs, KEV & Exploitation Data

Vulnerability statistics are easy to inflate because the biggest number, the raw count of published vulnerabilities, is also the least useful on its own. A record 48,244 vulnerabilities were disclosed in 2025, yet only a small fraction were ever exploited, and confirmed exploitation is concentrated in a tracked catalog far smaller than the disclosure total. This page separates the volume figures from the exploitation figures, sources each to its primary publisher, and explains why a page that counts every Common Vulnerabilities and Exposures (CVE) entry as a threat is measuring the wrong thing.

Last updated: August 2026. This page is a source audit, reviewed quarterly. You are welcome to cite it with a link back to ScanTitan.

Key vulnerability statistics at a glance

Each row states the figure, what it actually measures, the year of the underlying data, and the source, so an editor can quote it without misreading it.

What these numbers actually measure

Vulnerability statistics get misused when disclosure counts, exploitation counts, and breach counts are treated as one thing. Four distinctions carry most of the risk.

• Disclosure volume vs exploitation. Read the 48,244 CVEs as vulnerabilities disclosed, not as vulnerabilities exploited. Only a small fraction are ever weaponized, which is why raw CVE counts overstate real risk.
• KEV vs all CVEs. Treat “one third are content management system flaws” as a share of the Known Exploited Vulnerabilities (KEV) catalog, not of all CVEs. KEV is the exploited subset, not the whole.
• Vulnerability disclosures vs breaches. Note that a disclosed vulnerability is a potential entry point, not a breach. Breach vectors are measured separately, in reports like the Verizon DBIR.
• Different exploitation-timing datasets. Distinguish exploitation timing measured by VulnCheck from the broader estimate published by Mandiant. They use different populations and definitions, so their numbers should be cited side by side, not merged.

How many vulnerabilities are there?

Disclosure volume keeps setting records, and the trend line matters more than any single year. The public CVE program published 48,244 new vulnerabilities in 2025, a rise of about 20.4% on the 40,077 recorded in 2024, which was itself a roughly 38% jump on the 28,961 published in 2023 (CVE.org). Dividing the 2025 total across the year gives an average of about 132 new CVEs disclosed per day. Monthly volume has continued to climb into 2026, with individual months setting fresh records.

The critical qualifier is that a CVE is a disclosed vulnerability, not an exploited one. Most CVEs are never attacked in the wild, which is why counting all of them as active threats produces a scary but misleading picture. The useful signal is not how many vulnerabilities exist, but which ones are being exploited against software you actually run. Every figure in this section is drawn from the official CVE Program Metrics page rather than a secondary tracker, so the annual total and the daily average come from the same source.

Which vulnerabilities are actually exploited?

Confirmed exploitation is concentrated in a small, tracked population, which is what makes prioritization possible. CISA’s Known Exploited Vulnerabilities catalog, the authoritative United States record of vulnerabilities with evidence of exploitation in the wild, held on the order of 1,500 entries at the end of 2025, a number that sits far below the tens of thousands of vulnerabilities disclosed each year. That contrast is the point: the exploited fraction is small, and it is trackable.

Composition matters as much as count. VulnCheck reported that content management system flaws accounted for roughly one third of the KEVs in its first half 2026 dataset, the largest share of any technology category, which is directly relevant to anyone running a website. The Exploit Prediction Scoring System (EPSS), maintained by FIRST, gives each CVE an estimated probability of exploitation. Pairing EPSS with the KEV catalog is a widely used exploitation-aware way to cut a list of tens of thousands of CVEs down to the far smaller set that warrants urgent action.

How fast are vulnerabilities exploited?

The window between disclosure and exploitation has collapsed for the flaws attackers prioritize, which is the most important shift in the data. VulnCheck’s State of Exploitation report for the first half of 2026 found that 23.43% of KEVs showed exploitation evidence on or before the day the vulnerability was published, and that the median time from publication to KEV status was 80 days. Mandiant’s M-Trends 2026 put the broader estimated mean time to exploit at around negative seven days, meaning exploitation frequently begins before an official patch is available. These two figures come from different datasets and different definitions, so they belong side by side rather than merged into one number.

The practical stance is direct: a patch cadence tied to a quarterly cycle no longer matches attacker speed for internet facing systems. When a vulnerability is confirmed exploited, compensating controls such as a web application firewall (WAF) rule or a virtual patch matter in the hours before a vendor fix lands. A scheduled website vulnerability scanner that flags an exposed component against exploitation signals is the realistic way a lean team keeps pace.

Severity is not the same as priority

Severity and exploitation do not line up neatly, and treating a high score as a certainty of attack floods a small team with the wrong work. The Common Vulnerability Scoring System (CVSS) measures technical severity, not the probability that a vulnerability will be exploited. Many high severity vulnerabilities are never attacked in the wild, while some lower severity ones are exploited quickly, which is why severity alone is a poor sole ranking signal.

Three signals answer three different questions, and using them together is what makes prioritization defensible. CVSS estimates technical severity. The CISA KEV catalog provides confirmed evidence of exploitation. EPSS estimates the probability of future exploitation. KEV and EPSS are widely used exploitation-aware prioritization signals precisely because they capture what severity cannot. A clear stance follows from the data: rank by confirmed exploitation first, then by exploitation probability, then by severity, and always against what your environment actually runs.

Three signals answer three questions, and the table below shows how they divide the work. Using them together beats relying on any one, which is the practical core of modern vulnerability prioritization.

Used alone, each signal misleads: severity without exploitation floods the queue with theoretical risk, a KEV listing without severity context lacks impact, and a probability score without confirmation can miss an active attack. Used together, they turn a list of tens of thousands of disclosures into a short, ranked set of actions that a lean team can actually complete. The full EPSS methodology is published by FIRST, and it is refreshed daily as new exploitation evidence appears.

Where vulnerabilities enter a breach

Breach data now reflects the exploitation surge. Verizon’s 2026 Data Breach Investigations Report (DBIR) found that exploitation of software vulnerabilities was the leading initial access vector, present in 31% of breaches, up from 20% the prior year, a 55% increase, and the first time in the report’s 19 year history that exploitation overtook stolen credentials. Edge devices and virtual private network appliances featured heavily as the exploited entry points, since they sit on the internet and are often patched slowly. That 31% is a breach initial access measure, not a claim about how many websites are hacked through vulnerabilities.

Patching and remediation timelines

The core operational problem in the data is the gap between how fast vulnerabilities are exploited and how fast they are patched. Exploitation of the flaws attackers prioritize is frequently measured in hours, or begins before a patch exists, while organizational remediation of even confirmed exploited vulnerabilities routinely runs to weeks. That mismatch means a purely reactive, scheduled patch cycle leaves internet facing systems exposed during the highest risk window. The practical response has two parts. First, compensating controls such as a WAF rule or a virtual patch can hold the line in the hours or days before a vendor fix is applied. Second, prioritization has to be exploitation driven, so the small number of vulnerabilities under active attack jump the queue ahead of the large backlog of unexploited high severity findings. Continuous scanning is what turns that principle into a workable routine for a team without a dedicated vulnerability management function.

The data quality problem behind the numbers

A quieter 2026 development complicates every vulnerability statistic: the scoring and enrichment backlog at the United States National Vulnerability Database (NVD). On 15 April 2026, NIST announced a new risk based enrichment model for the NVD, and the details matter for anyone citing CVE data. All submitted CVEs will still be added to the NVD. NIST said it would prioritize enrichment for vulnerabilities in the CISA KEV catalog, for software used by the United States federal government, and for critical software as defined under Executive Order 14028. Non priority vulnerabilities may be labeled “Lowest Priority – not scheduled for immediate enrichment,” and backlogged CVEs with an NVD publish date earlier than 1 March 2026 are being moved into a “Not Scheduled” category.

The scale explains the change. NIST reported that CVE submissions increased 263% between 2020 and 2025, that submissions in the first three months of 2026 ran nearly one third higher than the same period a year earlier, and that it enriched nearly 42,000 CVEs in 2025, about 45% more than in any prior year. The consequence for statistics is precise: a published CVE count and a fully enriched NVD record count are no longer equivalent, so a growing share of vulnerabilities may appear without an official severity score at disclosure. This is not NIST abandoning CVEs, and an un enriched CVE is not automatically unimportant. It is a reason to lean on exploitation signals such as KEV and EPSS rather than a single official score. The full detail is in the NIST announcement.

From a vulnerability count to your real exposure

A national or global vulnerability count says nothing about a specific organization’s risk, and treating the two as related is a common analytical error. What determines exposure is the intersection of three things: which vulnerabilities are being actively exploited, which of those affect software the organization actually runs, and which of that software is reachable from the internet. A business that runs a handful of well maintained applications faces a tiny slice of the 48,244 disclosed CVEs, while a business with a sprawl of forgotten subdomains, abandoned plugins, and unmanaged services faces a far larger one, regardless of the global total. This is why asset discovery precedes vulnerability management: a vulnerability on software you do not run is not your problem, and a vulnerability on an asset you forgot you own is the one most likely to be exploited. Counting CVEs is easy; mapping them to a real, current inventory is the work that reduces risk, and it is why external attack surface discovery has become a companion to traditional scanning.

Read More: Small Business Cybersecurity Statistics (2026): Verified Data

Web application vulnerabilities in context

Website software deserves a brief mention here because it is internet facing by definition and heavily dependent on third party code, though the deeper treatment of website and content management system risk belongs on our website hacking statistics page. The scale is real: the WordPress ecosystem alone accounted for 11,334 disclosed vulnerabilities in 2025 (Patchstack), which supports the broader point that a single platform’s third party code can generate a large share of a site owner’s exposure. The lesson for vulnerability statistics is that a raw disclosure total hides this concentration, and the risk to a website owner is dominated by a trackable subset of exploited web flaws rather than the full count. Teams running site software benefit from platform specific coverage, such as a WordPress vulnerability scanner for the plugin heavy WordPress attack surface.

Statistics to stop citing

Honest vulnerability statistics means being careful with numbers that get stretched beyond what they measure.

• Raw CVE counts presented as a threat total. A figure like “48,244 vulnerabilities” describes disclosures, not dangers. Repeating it as though every entry threatens every organization overstates risk. Pair it with the KEV and EPSS context that shows how few are exploited.
• A single “percent exploited before patch” figure without its source population. Different datasets measure exploitation timing on different populations, so a lone percentage with no named source and population is not verifiable. Cite VulnCheck or Mandiant with the coverage period, and do not merge the two.
• Vendor CVE-count leaderboards read as security rankings. A high CVE count often reflects a broad product portfolio and an active disclosure program, not worse security. Do not present a vendor’s raw CVE tally as evidence that its software is more dangerous.

Source-lineage verification table

How to act on vulnerability data

The numbers point to a short, exploitation first workflow rather than chasing every CVE.

1. Prioritize by confirmed exploitation. Treat the CISA KEV catalog as the top of your queue, since it lists vulnerabilities with evidence of real world exploitation.
2. Add exploitation probability. Use EPSS to rank the large remainder, so effort follows likelihood rather than raw severity.
3. Match findings to your real stack. A vulnerability only matters if you run the affected software, so continuous discovery of what you expose comes first.
4. Scan on a schedule and virtual patch fast. With exploitation often preceding a fix, scheduled scanning plus compensating controls closes the window that manual, quarterly patching leaves open.

Methodology and sources

This page is a source audit of vulnerability statistics, built on a few principles: it separates disclosure volume from exploitation from breach data; it labels the KEV catalog as the exploited subset, not all CVEs; it cites each exploitation timing figure with its named dataset and coverage period rather than merging them; it notes the 2026 NVD enrichment change that affects any CVE count; and it refuses to present raw counts as threat totals or to keep numbers it cannot attribute to a named publisher. Primary and named sources include the CVE program at CVE.org, the United States National Vulnerability Database and the April 2026 NIST announcement, the CISA Known Exploited Vulnerabilities catalog, VulnCheck’s State of Exploitation reporting, the Verizon 2026 Data Breach Investigations Report, Mandiant M-Trends 2026, the FIRST Exploit Prediction Scoring System, and Patchstack’s State of WordPress Security in 2026. This page is reviewed quarterly. You are welcome to cite it with a link back to ScanTitan.

Frequently asked questions

Reviewed by Obaida Al-Sulaiman, Information Security Manager (CISSP, GWAPT, GXPN, GCIH, CEH), on August 19, 2026.