Vulnerability Exploitation Statistics 2026
By Axis Intelligence Research
Co-author: Marcus Chen | Last updated: August 13, 2026 | License: CC BY 4.0
Of the 49,183 CVEs published in 2025, Axis Intelligence Research finds that 184 have been confirmed exploited in the wild – one in every 267. Over the same period, vulnerability exploitation became the leading initial access vector in breaches for the first time in nineteen years of Verizon DBIR data. Both numbers are correct, and the distance between them is the whole problem.
Quick Answer
Confirmed exploitation is rare, and it drives most breaches. Axis Intelligence Research measures the Exploitation Conversion Rate (ECR) of the 2025 CVE cohort at 0.374% – 184 confirmed-exploited flaws out of 49,183 published, or 1 in 267. Across the entire CVE record set, 1,665 of 376,310 CVEs (0.442%) have ever entered CISA’s Known Exploited Vulnerabilities Catalog. Yet the Verizon 2026 DBIR puts vulnerability exploitation behind 31% of breach initial access, up from 20% a year earlier. Google Threat Intelligence Group counted 90 zero-days exploited in 2025, of which 43 (48%) hit enterprise technology – an all-time high.
Key Findings
- Axis Intelligence Research finds that 0.374% of CVEs published in 2025 have been confirmed exploited in the wild – 184 of 49,183, or one in 267.
- Axis Intelligence Research finds that 1,665 of the 376,310 CVE records held in the NIST National Vulnerability Database (0.442%) have ever been confirmed exploited by CISA, a rate of one in 226.
- Axis Intelligence Research finds that 90 of the 184 confirmed-exploited 2025-cohort vulnerabilities were exploited before a patch existed, meaning roughly half of confirmed exploitation in that cohort began as zero-day activity.
- Axis Intelligence Research finds that network edge and security appliances account for 18.4% of all confirmed-exploited vulnerabilities but 20.7% of those confirmed since January 2025, while browsers have collapsed to 1.4% of recent confirmations.
- Axis Intelligence Research finds that between 88% and 95% of a CVE cohort’s eventual confirmed exploitation is recorded by the end of the calendar year following the identifier year, meaning exploitation risk is resolved fast and late surprises are the exception.
What Percentage of Vulnerabilities Are Actually Exploited?
The question defenders actually ask is not how many vulnerabilities exist. It is how many matter.
Two primary feeds answer it. The CISA Known Exploited Vulnerabilities Catalog records vulnerabilities with reliable evidence of active exploitation in the wild. The NIST National Vulnerability Database CVE API records the total population of published CVEs. Dividing one by the other produces the base rate for exploitation.
| Measure | Value | As of | Source |
|---|---|---|---|
| CVE records in NVD | 376,310 | 2026-08-12 | NIST NVD CVE API 2.0 |
| Confirmed-exploited entries (KEV) | 1,665 | 2026-08-11 | CISA KEV Catalog v2026.08.11 |
| Share of all CVEs confirmed exploited | 0.442% | 2026-08-12 | Axis calculation |
| Odds | 1 in 226 | 2026-08-12 | Axis calculation |
That is the headline number for anyone building a prioritization argument: fewer than one CVE in two hundred has ever been confirmed exploited against a real target.
It is also a floor rather than a true rate. CISA requires an assigned CVE, reliable evidence of exploitation, and a clear remediation action before an entry is added. Commercial exploitation feeds routinely track broader sets. KEV is the conservative, government-attested measure, which is precisely why policy, contracts, and this analysis anchor on it.
Marcus Chen: The 0.442% figure gets quoted as though it settles the argument, and it does not. It is a lifetime ratio across a denominator stretching back to 1999, and the denominator is growing far faster than the numerator. What a security team needs is not the all-time rate but the rate for the cohort currently landing in their scanner. That number is different, and it is falling.
Source: axis-intelligence.com/vulnerability-exploitation-statistics/ — CC BY 4.0
The Exploitation Conversion Rate (ECR)
Lifetime ratios flatter nobody. A CVE published in 2013 has had thirteen years to be exploited; a CVE published last month has had weeks. Mixing them produces a number that describes the archive rather than the threat.
ECR – the Exploitation Conversion Rate – is an Axis Intelligence Research metric that measures the share of a single CVE cohort year that reaches confirmed exploitation in the wild. It replaces the lifetime ratio with a per-vintage rate that a vulnerability management team can actually plan against.
ECR formula and inputs
ECR(Y) = ( KEV entries whose CVE identifier year equals Y ÷ CVEs published in calendar year Y ) × 100
Both inputs are direct counts from primary feeds. Nothing is estimated, modelled, or smoothed.
| Cohort | Confirmed exploited | CVEs published | ECR | Odds | Numerator source | Denominator source |
|---|---|---|---|---|---|---|
| 2024 | 164 | 40,704 | 0.403% | 1 in 248 | CISA KEV Catalog | FIRST vulnerability forecast review |
| 2025 | 184 | 49,183 | 0.374% | 1 in 267 | CISA KEV Catalog | FIRST vulnerability forecast review |
| Lifetime (all cohorts) | 1,665 | 376,310 | 0.442% | 1 in 226 | CISA KEV Catalog | NIST NVD CVE API 2.0 |
The 2025 denominator comes from FIRST’s 2025 Vulnerability Forecast year-end review, which recorded 49,183 CVEs published with two days left in the calendar year against a February prediction of 45,505 plus or minus 4,363. The 2024 figure of 40,704 comes from the same forecasting team’s year-in-review for that year.
What ECR says: confirmed exploitation grew in absolute terms between the two cohorts, from 164 flaws to 184. As a rate it fell, from 0.403% to 0.374%, because disclosure volume grew faster than exploitation did. Attackers did not slow down. The haystack got bigger.
Cohort maturity: is the 2025 ECR final?
A fair objection to any cohort rate is that recent cohorts have not finished converting. Axis Intelligence Research tested this directly against the catalog.
| Cohort | Confirmed by end of following year | Total confirmed to date | Share resolved early |
|---|---|---|---|
| 2022 | 115 | 131 | 87.8% |
| 2023 | 147 | 164 | 89.6% |
| 2024 | 155 | 164 | 94.5% |
Between 88% and 95% of a cohort’s eventual confirmed exploitation is recorded by the close of the following calendar year, and the share has risen across the three matured cohorts. The 2025 ECR of 0.374% is therefore close to final. It will move, but not by much, and the direction of travel in the matured cohorts suggests it will move less than the 2022 cohort did.
Scope note: the numerator counts CVE identifier year; the denominator counts calendar-year publication. The two definitions diverge at the margin, because an identifier reserved in December of year Y may publish in January of year Y+1. FIRST’s own forecasting team flags the same distinction in its methodology. Axis Intelligence Research discloses the mismatch rather than smoothing it, and estimates its effect at well under one tenth of a percentage point on ECR at current volumes.
Is Vulnerability Exploitation Increasing or Decreasing?
Both, depending on which end of the pipe is measured.
At the disclosure end, growth is close to vertical. FIRST’s February 2026 forecast put the median expectation at 59,427 CVEs for the year, with a 90% interval running from 30,012 to 117,673. By June the 2026 mid-year vulnerability forecast had revised that to roughly 66,000, after actual disclosures ran 46.3% above the original projection – an excess of 6,420 CVEs through April alone. FIRST attributes the surge to AI-assisted vulnerability discovery, a 449% year-over-year rise in GitHub Security Advisory volume, and a 3,119% increase in CVE Numbering Authority activity from VulnCheck rather than to any collapse in software quality.
At the exploitation end, the picture is flat. FIRST’s own forecasting team, in the 2026 forecast update, filtered the disclosure surge down to vulnerabilities that are either in the KEV catalog or carry an EPSS score above 10%, and found the actionable remediation burden completely flat. Their metaphor is precipitation: total rainfall is up sharply, the flood line has not moved.
The catalog confirms it. Confirmed-exploitation additions by calendar year:
| Year | KEV additions | Note | Source |
|---|---|---|---|
| 2021 (from Nov 3) | 311 | Catalog established | CISA KEV Catalog |
| 2022 | 555 | Historical backfill | CISA KEV Catalog |
| 2023 | 187 | Steady state begins | CISA KEV Catalog |
| 2024 | 186 | – | CISA KEV Catalog |
| 2025 | 245 | – | CISA KEV Catalog |
| 2026 (to Aug 11) | 181 | Partial year | CISA KEV Catalog |
Set 2021 and 2022 aside as cataloging effort rather than attacker behaviour. What remains is a band running from 186 to 245 additions per year while annual CVE publication roughly doubled. Axis Intelligence Research finds that a second cross-source reading confirms the same shape: at May 1, 2026, FIRST recorded EPSS scores for 329,934 CVEs against a KEV catalog of 1,587 entries, a confirmed-exploitation share of 0.481% on that date.
Marcus Chen: This is the single most useful finding for anyone defending a security budget. Disclosure volume is not a threat metric. If your programme scales headcount and tooling against CVE count, you are indexing to a number driven by AI-assisted research output and CNA onboarding, neither of which is an adversary. The exploited set has grown by tens of entries per year while the published set grew by tens of thousands. Index to the exploited set.
How Much of Confirmed Exploitation Starts as a Zero-Day?
This is where the rare-event framing stops being reassuring.
Google Threat Intelligence Group’s annual review, Look What You Made Us Patch: 2025 Zero-Days in Review, tracked 90 vulnerabilities exploited in the wild before a patch was publicly available in 2025. That sits above 2024’s 78 and below the 2023 record of 100, within a 60 to 100 band that has held for five years.
| Zero-day measure | 2023 | 2024 | 2025 | Source |
|---|---|---|---|---|
| Zero-days exploited in the wild | 100 | 78 | 90 | Google Threat Intelligence Group |
| Enterprise technology zero-days | – | 36 | 43 | Google Threat Intelligence Group |
| Enterprise share of total | – | 46% | 48% | Google Threat Intelligence Group |
| Security and networking appliance zero-days | – | – | 21 | Google Threat Intelligence Group |
| Mobile platform zero-days | – | 9 | 15 | Google Threat Intelligence Group |
| Browser zero-days | – | – | 8 | Google Threat Intelligence Group |
Set the 90 zero-days against the 184 confirmed-exploited flaws in the 2025 CVE cohort and the ratio is stark.
Axis cross-source calculation: 90 zero-days exploited in 2025 (Google Threat Intelligence Group, as of 2026-03-05) ÷ 184 KEV entries carrying a CVE-2025 identifier (CISA KEV Catalog v2026.08.11, as of 2026-08-11) × 100 = 48.9%. The two datasets are independently constructed and their memberships are not identical, so this is a magnitude comparison rather than a subset calculation. It is disclosed as such.
Roughly half of the confirmed exploitation in the 2025 cohort involved a flaw that was being used against real systems before a fix existed. For that half, patch speed was not a variable. Nothing in a remediation SLA can act on a vulnerability the vendor has not yet acknowledged.
Google also recorded that commercial surveillance vendors were attributed more zero-day exploitation than state-sponsored espionage groups for the first time since tracking began, that PRC-nexus groups used at least ten zero-days, double the 2024 count, and that nine zero-days were attributed to financially motivated actors against five the year before.
Marcus Chen: The zero-day share is the number that should reorganise a security programme. If half of what gets exploited in a given cohort was exploited pre-patch, then half of your exposure is not a patching problem at all – it is a detection, segmentation, and blast-radius problem. The organisations that survived the 2025 edge-device campaigns were not the ones who patched fastest. They were the ones who knew which appliances were internet-facing without running a scan to find out.
Which Technology Segments Get Exploited Most?
Vendor rankings are widely published and mostly measure installed base. Segment analysis is not published, and it is where the behavioural shift is visible.
Axis Intelligence Research classified all 1,665 catalog entries into six technology segments using the vendor and product fields, then compared each segment’s lifetime share against its share of the 426 entries confirmed since January 1, 2025.
| Segment | Lifetime entries | Lifetime share | Ransomware-linked | Confirmed since Jan 2025 | Recent share | Direction |
|---|---|---|---|---|---|---|
| Enterprise application and other | 671 | 40.3% | 20.6% | 205 | 48.1% | Rising |
| Network edge and security appliance | 306 | 18.4% | 23.5% | 88 | 20.7% | Rising |
| Operating system and hypervisor | 292 | 17.5% | 24.7% | 66 | 15.5% | Falling |
| Vendor platform and productivity | 285 | 17.1% | 16.5% | 51 | 12.0% | Falling |
| Browser and browser engine | 88 | 5.3% | 8.0% | 6 | 1.4% | Collapsing |
| CMS and web plugin | 23 | 1.4% | 13.0% | 10 | 2.3% | Rising from near zero |
Source for all rows: Axis calculation on CISA KEV Catalog v2026.08.11. Segment definitions are listed in Methodology.
Three findings come out of this table that no vendor ranking surfaces.
Browsers have effectively left the confirmed-exploitation set
Browsers and browser engines hold 88 lifetime entries but only six confirmed since January 2025 – a fall from 5.3% of the catalog to 1.4% of recent additions. Google’s independent count moves the same way, with browser zero-days down to eight in 2025 from far higher counts in earlier years. Two decades of sandboxing, site isolation, and rapid auto-update have produced the clearest measurable security win in the dataset.
CMS and plugin flaws are the largest disclosure-to-exploitation gap in the industry
WordPress plugin security firms operating as CVE Numbering Authorities now publish CVEs in volumes rivalling the largest platform vendors, and that volume is a substantial share of the disclosure surge FIRST is tracking. Confirmed exploitation of that entire segment stands at 23 lifetime entries – 1.4% of the catalog.
That is the most extreme asymmetry in the data. A vulnerability management queue sorted by raw CVE count will be dominated by a segment responsible for roughly one in seventy confirmed-exploitation events. The segment is not harmless, and it is growing: ten of the 23 entries arrived after January 2025, and eight of the most recent carry 2026 identifiers. But its exploitation rate per disclosed flaw is an order of magnitude below the enterprise segments.
Perimeter and enterprise application flaws now dominate recent exploitation
Network edge and security appliances hold 18.4% of the lifetime catalog and 20.7% of recent confirmations, with a 23.5% ransomware linkage rate. Enterprise applications and other server-side software supply 48.1% of recent confirmations against a 40.3% lifetime share. Google’s zero-day data agrees from a different direction: 21 of the 43 enterprise zero-days in 2025 hit security and networking appliances specifically.
The logic is not mysterious. Appliances terminate untrusted traffic by design, run firmware that cannot host endpoint detection agents, and sit at a network position that converts a single flaw into broad access.
Marcus Chen: Read the ransomware column, not the volume column. Operating systems and hypervisors carry the highest linkage at 24.7%, edge appliances 23.5%, browsers 8.0%. Volume tells you where attackers spend their time. Linkage tells you what happens to your organisation when they succeed. The segments trending up in recent confirmations are also the segments with the highest ransomware conversion, which is the least comfortable combination in this dataset.
How Often Does Exploitation Actually Cause a Breach?
Rarity at the CVE level does not translate into rarity at the incident level, and conflating the two is the most common analytical error in this subject.
The Verizon 2026 Data Breach Investigations Report, drawn from more than 22,000 confirmed breaches across 145 countries covering November 2024 to October 2025, found that exploitation of vulnerabilities became the leading initial access vector for the first time in the report’s nineteen-year history.
| Initial access vector | 2026 DBIR share | Prior year | Source |
|---|---|---|---|
| Exploitation of vulnerabilities | 31% | 20% | Verizon 2026 DBIR |
| Phishing | 16% | – | Verizon 2026 DBIR |
| Credential abuse | 13% | – | Verizon 2026 DBIR |
| Pretexting (newly tracked) | 6% | – | Verizon 2026 DBIR |
| Credential abuse anywhere in the breach chain | 39% | – | Verizon 2026 DBIR |
The DBIR is explicit that part of the credential-abuse decline is definitional, since pretexting was separated into its own vector this year; without that change credential abuse would have registered at 16% rather than 13%. On a like-for-like basis, identity-related initial access remains close to vulnerability exploitation in size. What is not definitional is the eleven-point rise in exploitation, which continued a three-year climb.
The remediation data in the same report explains how a 0.374% conversion rate produces a 31% breach share.
| Remediation measure | 2026 DBIR | Prior year | Source |
|---|---|---|---|
| CISA KEV entries fully remediated | 26% | 38% | Verizon 2026 DBIR |
| Median time to full resolution | 43 days | 32 days | Verizon 2026 DBIR |
Remediation of the confirmed-exploited set went backwards. Roughly three quarters of KEV vulnerabilities present in studied environments were not fully remediated, and the median resolution time extended by eleven days.
That is the mechanism. The exploited set is small, well-published, and freely available as a machine-readable feed. It is also mostly unpatched. Attackers are not winning on discovery. They are winning on the gap between a list everyone can download and a fix nobody has finished deploying.
Marcus Chen: Put the two numbers next to each other and the strategic conclusion writes itself. Thirty-one percent of breaches start with exploitation of a vulnerability, and only twenty-six percent of the vulnerabilities we already know are being exploited get fully fixed. This is not an intelligence failure. Every organisation in that dataset could have downloaded the list. It is an execution failure, and execution failures respond to different interventions than intelligence failures do.
How Fast Does Exploitation Follow Disclosure?
The cohort data answers this without requiring any vendor telemetry.
Of the 1,665 catalog entries, 110 carry a 2026 identifier and were confirmed exploited during 2026 – every 2026-cohort entry in the catalog was confirmed in the same calendar year it was named. For the 2025 cohort, 151 of 184 were confirmed within the identifier year itself. For 2024, 116 of 164.
Combined with the maturity table above, the shape is consistent: exploitation of a given vulnerability, when it happens at all, happens quickly. Between 88% and 95% of a cohort’s confirmed exploitation lands by the end of the following year, and a clear majority lands inside the identifier year.
The practical reading is that a vulnerability’s exploitation risk is largely determined in its first eighteen months. A CVE that has been public for three years without confirmed exploitation is unlikely to acquire it, which is the empirical basis for aging out old low-severity findings rather than carrying them forever. The exceptions are real and occasionally spectacular – the catalog contains entries with identifiers from 2002 – but they are exceptions, and a queue built around them is a queue built around the tail.
What Does This Mean for Prioritization?
Four numbers, all from primary feeds, define the working model.
- 0.374% of the 2025 cohort has been confirmed exploited. Sorting by CVSS severity across the full cohort sorts a haystack.
- 31% of breaches begin with exploitation. The needles are sharp.
- 26% of confirmed-exploited vulnerabilities get fully remediated. The list is public and largely unactioned.
- 48.9% of confirmed exploitation in the 2025 cohort began pre-patch. Half the problem is not solvable by patching speed at all.
FIRST’s forecasting team reached the operational version of the same conclusion from their own data: teams using exploitability-based triage should not need to scale headcount in line with total CVE volume. The exploited set is not growing at the rate of the published set, and it has not been for four years.
Methodology
Collection. The complete CISA Known Exploited Vulnerabilities Catalog was retrieved on August 13, 2026 at catalog version 2026.08.11, released 2026-08-11T18:59:43Z with a declared count of 1,665, via CISA’s cisagov/kev-data repository, which mirrors the agency’s published JSON and CSV files with commit history. Total CVE population was read from the NIST NVD CVE API 2.0 response metadata, which returned 376,310 records at timestamp 2026-08-12T16:35:42. Annual CVE publication counts for 2024 and 2025 were taken from the FIRST vulnerability forecasting team’s published year-end reviews. Zero-day counts were taken from Google Threat Intelligence Group’s 2025 annual review. Breach-vector and remediation figures were taken from the Verizon 2026 Data Breach Investigations Report as published.
ECR construction. ECR(Y) = (count of KEV entries whose cveID year component equals Y ÷ CVEs published in calendar year Y) × 100. The numerator is a direct parse of the catalog; no entry was hand-transcribed. The denominator is the published calendar-year total from FIRST. Odds are expressed as 1 in (denominator ÷ numerator), rounded to the nearest integer. The lifetime row substitutes the NVD record count as denominator and the full catalog as numerator.
Cohort maturity test. For cohorts 2022, 2023, and 2024, entries were counted where the dateAdded year equals the identifier year or the identifier year plus one, and expressed as a share of that cohort’s total confirmed entries at this snapshot. Cohorts before 2022 are excluded because the catalog did not exist for their first year and the resulting figures would measure cataloging start date rather than exploitation timing. The 2025 and 2026 cohorts are excluded because they cannot yet fail the test.
Segment classification. Six mutually exclusive segments assigned by vendorProject and product string. Network edge and security appliance: Ivanti, Fortinet, Citrix, SonicWall, Palo Alto Networks, Cisco, Zyxel, D-Link, NETGEAR, F5, Check Point, Juniper Networks, Sophos, Barracuda Networks, Array Networks, Pulse Secure, WatchGuard, TP-Link, DrayTek, Progress, Sangfor, Ruckus Wireless. CMS and web plugin: product or vulnerability name matching WordPress, plugin, Joomla, Drupal, Magento. Browser and browser engine: Chrome, Firefox, Safari, WebKit, Edge, Internet Explorer. Operating system and hypervisor: platform-vendor entries matching Windows, macOS, iOS, Android, Linux kernel, ESXi, vCenter, hypervisor, or server. Vendor platform and productivity: remaining entries from Microsoft, Apple, Google, Linux, Red Hat, Oracle, IBM. Enterprise application and other: all remaining entries. Vendors shipping both appliance and non-appliance products are counted whole under their assigned segment, which modestly inflates the edge segment, most notably for Cisco. The same classification is applied identically to the lifetime and recent cohorts so that the comparison is internally consistent.
Cross-source comparisons. Where figures from independently constructed datasets are set against each other – Google zero-day counts against KEV cohort counts, EPSS coverage against KEV size – the calculation is labelled as a magnitude comparison and the differing definitions are stated at the point of use. Memberships are not assumed to be subsets.
Scope. KEV records confirmed exploitation with an assigned CVE and a clear remediation action, so it undercounts real-world exploitation by design and its additions reflect CISA analyst capacity as well as attacker behaviour. Google’s zero-day count reflects exploitation tracked by GTIG and its own report notes that figures may adjust as past incidents surface. The Verizon dataset is drawn from contributing incident-response organisations and is not a random sample of all breaches. Where two sources disagree in framing, this analysis publishes both readings rather than reconciling them silently.
Verification. Every figure was computed in Python directly from the retrieved catalog and re-run in an independent second pass. The catalog’s declared count of 1,665 matches the parsed entry count exactly. The 2025 addition total of 245 and the year-end 2025 catalog size of 1,484 reconcile with figures independently reported for that date. Every number in this article corresponds to a row in the accompanying CSV.
About This Dataset
vulnerability-exploitation-statistics-2026.csv contains every numeric claim in this article as a structured row: ECR values and their inputs for each cohort, cohort maturity ratios, annual KEV additions, the six-segment classification with lifetime counts, recent counts, and ransomware linkage rates, Google zero-day counts by category and year, Verizon DBIR initial-access shares and remediation figures, and FIRST disclosure volumes and forecasts.
Each row carries metric, value, unit, dimension, as_of_date, source_org, source_document, source_url, retrieved_date, is_primary, axis_calculated, method_note, and license. Values are raw – no currency symbols, no percent signs, no thousands separators. Dates are ISO 8601. Rows marked axis_calculated = yes carry a method_note naming the formula disclosed above.
License: CC BY 4.0. Free to use, redistribute, and build on with attribution.
Distribution: the dataset is mirrored to Hugging Face, Kaggle, and GitHub under the same licence.
Cite This Research
APA Axis Intelligence Research. (2026). Vulnerability exploitation statistics 2026: How many CVEs are actually exploited in the wild. https://axis-intelligence.com/vulnerability-exploitation-statistics/
MLA Axis Intelligence Research. “Vulnerability Exploitation Statistics 2026: How Many CVEs Are Actually Exploited in the Wild.” Axis Intelligence, 13 Aug. 2026, axis-intelligence.com/vulnerability-exploitation-statistics/.
Chicago Axis Intelligence Research. “Vulnerability Exploitation Statistics 2026: How Many CVEs Are Actually Exploited in the Wild.” Axis Intelligence, August 13, 2026. https://axis-intelligence.com/vulnerability-exploitation-statistics/.
ECR attribution: ECR (Exploitation Conversion Rate) is a proprietary metric of Axis Intelligence Research, licensed CC BY 4.0. Cite as: Axis Intelligence Research, Exploitation Conversion Rate, 2025 cohort reading 0.374%, August 11, 2026, axis-intelligence.com/vulnerability-exploitation-statistics/.
Frequently Asked Questions
If only 0.374% of CVEs are exploited, why does my scanner flag thousands as critical?
Because CVSS measures theoretical severity in an abstract environment, not observed exploitation in yours. A CVSS 9.8 rating describes what an attacker could do if the flaw were reachable and weaponised; it says nothing about whether either condition holds. The gap between the two is the entire finding of this analysis. Exploitation-aware inputs – KEV membership, EPSS probability, asset exposure – are what convert a severity list into a work queue.
Should I treat EPSS and KEV as alternatives or as layers?
Layers, and they answer different questions. KEV is a binary, retrospective, government-attested observation that exploitation has occurred. EPSS is a continuous, forward-looking probability estimate maintained by FIRST across a far larger population – 329,934 scored CVEs at May 1, 2026 against 1,587 KEV entries on the same date. KEV tells you what has already been used. EPSS tells you what is likely to be used next. A queue built on either alone will miss what the other catches.
Does a low Exploitation Conversion Rate justify slowing down patching?
No, and the DBIR data is the reason. The conversion rate is low and the breach share is high precisely because the small exploited set is poorly remediated – 26% full remediation, down from 38%. A low ECR is an argument for concentrating effort, not reducing it. The correct response is to move resources off the 99.6% that will never be exploited and onto the fraction that already has been, then actually finish the job on that fraction.
How should I handle the half of exploitation that starts as a zero-day?
Not with patching policy, because there is nothing to patch at the moment of exposure. The controls that operate in that window are architectural: knowing which assets are internet-facing without running a discovery scan, segmenting appliance management planes, monitoring for post-exploitation behaviour on devices that cannot host an endpoint agent, and holding the ability to take an appliance off the internet as a deliberate, pre-authorised action rather than an emergency decision.
Why are WordPress plugin vulnerabilities such a small share of confirmed exploitation?
Three structural reasons. Confirmed exploitation requires attribution, and mass automated exploitation of small sites produces far less incident-response reporting than one appliance compromise inside a federal agency. CISA’s catalog scope is anchored to federal-relevant technology, where plugin estates are thin. And the return per compromise differs by orders of magnitude. The 1.4% share is a real measurement of the confirmed set, and it should be read as evidence about visibility and attacker economics rather than as proof that the segment is safe.
Is the collapse in browser exploitation real or a detection artefact?
Both effects are present, and Google says so directly – it attributes part of the decline in observed browser zero-days to improved attacker operational security, not only to better browser defences. That said, two independent datasets move together here: browsers fell to 1.4% of recent KEV confirmations and to eight zero-days in the Google count. Sandboxing, site isolation, and silent auto-update genuinely raised the cost of browser exploitation. The honest reading is a large real improvement with an unquantified detection component on top.
Can I reproduce these numbers myself?
Yes, and that is the point of publishing the formula and the segment definitions. Download the KEV catalog at version 2026.08.11, parse the cveID year component, and divide the per-year counts by the published CVE totals for those years. Every figure in the article follows from those two inputs plus the cited third-party counts. The accompanying CSV carries each value with its source document and retrieval date so that individual rows can be checked without re-running the whole analysis.
Why does ECR use CVE identifier year rather than publication date?
Because the KEV catalog does not carry a CVE publication date, only the date CISA added the entry. Identifier year is the only cohort marker available on both sides of the ratio without joining every entry against a second API. The two definitions diverge for identifiers reserved late in one year and published early in the next, an effect this analysis estimates at well under a tenth of a percentage point at current volumes and discloses rather than corrects.
How does this differ from measuring exploitation with a commercial threat feed?
Commercial feeds apply looser evidentiary standards and consequently track larger exploited sets, which produces higher conversion rates than the ones here. Neither approach is wrong. KEV is the conservative floor: it requires an assigned CVE, reliable evidence, and a clear remediation action, and it is the standard referenced in federal directives and increasingly in contract language. Any number derived from it should be read as a minimum, and any comparison across sources should state which evidentiary standard produced it.
Related Research
- CISA KEV Statistics – catalog growth, vendor concentration, and the BOD 26-04 remediation clock
- CVE Statistics – disclosure volume, severity distribution, and affected vendors
- Zero-Day Tracker – live record of zero-day exploitation events
- Cybersecurity Statistics – the wider incident and cost dataset
- Malware Statistics – payload and family-level data
- AI Cyberattack Statistics – AI-assisted offensive activity
- Patch Management Statistics