# CISA Known Exploited Vulnerabilities: Operational Patterns Across 1,709 KEV Records

> A census of 1,709 CISA KEV records measures remediation windows, vendor concentration, ransomware association and forensic-triage signals, then builds an asset-aware evidence queue.

- Canonical page: https://mtfinstitute.com/insights/cisa-kev-1709-vulnerabilities-remediation-ransomware-forensic-triage-september-2026/
- Content type: Article
- Editorial category: Research & Reports
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Editorial Team- Published: 2026-09-14
- Updated: 2026-09-14
- Language: English
- Topics: Cybersecurity GRC, CISA KEV, Vulnerability Management, Ransomware, Forensic Triage

Which known exploited vulnerabilities deserve action first when a security team cannot remediate everything at once? This MTF Research Report analyses all 1,709 records in the U.S. Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities catalogue version 2026.09.11. It measures remediation windows, vendor and product concentration, ransomware association, weakness categories and the new forensic-triage field, then translates the findings into an evidence-based operating queue.

**Report number:** MTF-RR-2026-09-14-01  
**Publication date:** 14 September 2026  
**Author:** MTF Institute Editorial Team  
**Reviewer:** Igor Dmitriev  
**Sample:** 1,709 CISA KEV records  
**DOI:** [10.5281/zenodo.22745188](https://doi.org/10.5281/zenodo.22745188)  
**Archival PDF:** [Download the searchable report](https://zenodo.org/records/22745188/files/MTF-RR-2026-09-14-01.pdf?download=1)

## Research question

What operational patterns appear across the complete CISA Known Exploited Vulnerabilities catalogue as of 11 September 2026? Specifically:

1. How much remediation time does the catalogue assign between date added and due date?
2. How concentrated are catalogue records by vendor and product?
3. How often does CISA mark known ransomware campaign use?
4. Which CWE weakness identifiers occur most often among records with published CWE data?
5. What does the 2026 forensic-triage field add to a practical vulnerability response queue?

The report does not rank vulnerabilities by universal danger. A CVE becomes an organizational risk only when a relevant asset, affected version, exposure path and business consequence exist. The catalogue supplies high-value exploitation evidence; the organization must add asset and control context.

## Short answer

The catalogue is large and diverse: 1,709 vulnerabilities across 283 published vendor names and 720 vendor-product combinations. The median interval from addition to due date is 21 days, but the mean is 42.5 days and the range is one to 184 days. Sixty percent of all records fall in the 15-to-21-day band, while 6.4% allow three days or less. This means a team cannot turn “KEV” into one undifferentiated service-level agreement without losing information contained in CISA's own dates.

CISA marks 360 records, or 21.1%, as associated with known ransomware campaigns. Microsoft accounts for 388 records, 22.7% of the catalogue; the next four published vendor names are Cisco with 97, Apple with 94, Adobe with 81 and Google with 74. This concentration does not mean those vendors are inherently less secure. It shows why asset inventory and product ownership are necessary: a small number of technology ecosystems can generate a large share of the response workload.

The forensic-triage field is marked “Yes” for 51 records, all among the 225 catalogue additions in 2026 in this snapshot. It should create an evidence-preservation branch in the workflow, not merely a faster patch ticket. The practical conclusion is a two-stage queue: first verify applicability and exposure; then combine the assigned due date with business criticality, exploit evidence, ransomware association, forensic need, control options and recovery readiness.

## Scope and source

The source is CISA's public [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), downloaded as JSON on 14 September 2026. The file identifies catalogue version 2026.09.11 and release time 11 September 2026 at 19:32 UTC. We included every one of the 1,709 vulnerability objects in the file.

CISA describes the catalogue as an authoritative source of vulnerabilities exploited in the wild and requires U.S. Federal Civilian Executive Branch agencies to remediate listed vulnerabilities under binding operational directives. Other organizations can use it as an input to prioritization. The due date is a CISA catalogue field; it is not a universal legal deadline for every private or non-U.S. organization.

The analytical unit is one KEV catalogue record identified by CVE. We did not scan systems, verify whether an exploit works, calculate CVSS scores or estimate loss. We preserved vendor and product strings as published rather than merging corporate families or normalizing brand history.

## Inclusion, exclusion and calculation rules

All 1,709 records were included because each had a CVE identifier, vendor, product, date added, due date, vulnerability name, required action and ransomware-use field. No record was sampled out.

For each record, remediation-window days equal the ISO due date minus the ISO date added. Calendar days are used. We grouped the result into six descriptive bands: zero to three, four to seven, eight to fourteen, fifteen to twenty-one, twenty-two to thirty and more than thirty days.

Vendor concentration counts the exact `vendorProject` value. Product diversity counts unique vendor-product pairs, which avoids treating identically named products from different vendors as one. Ransomware association counts records where `knownRansomwareCampaignUse` equals “Known”; “Unknown” means CISA has not marked known use in that field, not proof that ransomware actors have never used the vulnerability.

CWE analysis is multi-response. A vulnerability with two CWE identifiers contributes once to each. Percentages for CWE therefore use the total number of published CWE assignments as their denominator and do not sum to the number of vulnerabilities. Records without a CWE contribute to no CWE count.

The forensic-triage analysis preserves “Yes” and “No” exactly. The field appears in the current catalogue design, but the snapshot should not be used to infer a historical negative for older records without considering changes to CISA's process and directives.

All calculations are descriptive. No statistical inference, causal test or forecast was performed.

## Catalogue composition by year added

| Year added | KEV records | Share of catalogue |
| --- | ---: | ---: |
| 2021 | 311 | 18.2% |
| 2022 | 555 | 32.5% |
| 2023 | 187 | 10.9% |
| 2024 | 186 | 10.9% |
| 2025 | 245 | 14.3% |
| 2026 through 11 September | 225 | 13.2% |
| **Total** | **1,709** | **100.0%** |

The large 2021 and 2022 shares reflect the catalogue's launch and expansion, not necessarily that exploitation peaked in those years. Date added is the date CISA added a CVE to KEV, not the disclosure date, first exploitation date or software release date. Teams should never interpret the year table as an incident timeline.

The operational value is workload history. A mature organization needs both a new-addition process and a residual check for older catalogue items that remain on unsupported or overlooked assets.

## Remediation windows

| Date-added to due-date window | Records | Share |
| --- | ---: | ---: |
| 0–3 days | 110 | 6.4% |
| 4–7 days | 29 | 1.7% |
| 8–14 days | 281 | 16.4% |
| 15–21 days | 1,025 | 60.0% |
| 22–30 days | 2 | 0.1% |
| 31+ days | 262 | 15.3% |

The median is 21 days. The shortest window is one day and the longest is 184 days. The mean of 42.5 days is much higher than the median because a group of long-window records stretches the distribution.

Three operational conclusions follow.

First, a 21-day default can describe the centre of the catalogue but cannot replace the record-specific date. A team that batches every KEV into the next monthly maintenance window will miss one-to-fourteen-day assignments.

Second, short windows require pre-built authority. The organization cannot begin asset discovery, business-owner identification, backup verification, change approval and incident-evidence planning after a three-day item arrives. These capabilities must exist before the alert.

Third, long historical windows should not become permission for indefinite delay. The relevant question today is whether an affected asset still exists and remains exposed, not how generous an old deadline once appeared.

## Vendor and product concentration

| Published vendor name | Records | Share |
| --- | ---: | ---: |
| Microsoft | 388 | 22.7% |
| Cisco | 97 | 5.7% |
| Apple | 94 | 5.5% |
| Adobe | 81 | 4.7% |
| Google | 74 | 4.3% |
| Oracle | 46 | 2.7% |
| Apache | 40 | 2.3% |
| Ivanti | 35 | 2.0% |
| Fortinet | 30 | 1.8% |
| Linux | 28 | 1.6% |

The top five published vendor names account for 734 records, or 43.0% of the catalogue. Yet the full catalogue spans 283 vendor names and 720 vendor-product combinations. Vulnerability operations therefore face concentration and long-tail diversity at the same time.

The concentration supports ecosystem ownership. Large technology estates need named owners who understand release channels, unsupported versions, compatibility testing and rollback. The long tail supports reliable inventory and supplier coordination: an obscure device, plugin or appliance can still be business-critical and exposed.

The counts must not be used as a vendor security league table. Vendors differ in installed base, product age, research attention, disclosure practice, catalogue naming and the number of products represented. A count measures catalogue workload, not a probability that a new purchase will be compromised.

## Known ransomware campaign use

CISA marks 360 vulnerabilities as “Known” ransomware campaign use, 21.1% of the catalogue. The remaining 1,349 records, 78.9%, are “Unknown.”

The useful interpretation is asymmetric. A “Known” value is additional threat evidence and should be visible to the decision owner. An “Unknown” value is absence of that published confirmation, not a safety label. A vulnerability can still be exploited for espionage, access brokerage, disruption or other objectives.

A queue should therefore include ransomware association as one factor, not a binary gate. Organizations with critical recovery dependencies may assign additional urgency to a known-ransomware item, but they still need to confirm affected assets, exposure and compensating controls.

## Forensic-triage signal in 2026

The snapshot contains 225 records added during 2026. CISA marks forensic triage “Yes” for 51 and “No” for 174. Across the whole catalogue, those 51 represent 3.0%.

This field changes the operating question. Patching removes or reduces a technical exposure; forensic triage asks whether the organization should preserve and examine evidence that compromise may already have occurred. If a team patches first and destroys logs, volatile data or indicators, it can close the ticket while losing the ability to understand impact.

The correct branch depends on current CISA instructions, asset context and incident-response policy. A “Yes” flag should notify security operations and incident-response owners, identify evidence sources, protect chain of custody where applicable and coordinate containment with remediation. It should not cause an untrained team to collect sensitive evidence without authorization.

## Weakness patterns

The most frequent published CWE assignments were:

| CWE | Assignments | Share of all CWE assignments |
| --- | ---: | ---: |
| CWE-20 Improper Input Validation | 118 | 7.2% |
| CWE-78 OS Command Injection | 110 | 6.7% |
| CWE-787 Out-of-bounds Write | 103 | 6.2% |
| CWE-416 Use After Free | 93 | 5.6% |
| CWE-119 Memory Buffer Bounds | 85 | 5.2% |
| CWE-22 Path Traversal | 78 | 4.7% |
| CWE-502 Deserialization of Untrusted Data | 71 | 4.3% |
| CWE-94 Code Injection | 70 | 4.2% |
| CWE-287 Improper Authentication | 47 | 2.9% |
| CWE-306 Missing Authentication for Critical Function | 42 | 2.5% |

These counts show recurring technical weakness families in exploited products. They do not tell a defender which internal asset is most urgent. They can, however, support secure-development learning, supplier questions and control testing. For example, command injection and code injection emphasize input handling and execution boundaries; authentication weaknesses emphasize identity and access control; memory-safety categories emphasize platform and language risk.

Because CWE is multi-response and not complete for every record, the table is a pattern inventory, not a mutually exclusive taxonomy.

## Practical application: the KEV-ACT-8 queue

The research supports an eight-part decision record for each applicable KEV.

| Step | Decision question | Evidence retained |
| --- | --- | --- |
| **K — Known applicability** | Is an affected product and version actually present? | verified asset and version record |
| **E — Exposure** | Can the vulnerable function be reached or abused in the current architecture? | exposure path and control evidence |
| **V — Vulnerability instruction** | What do CISA and the vendor require, and by when? | dated advisory and due date |
| **A — Asset consequence** | What business service, data and dependency could be affected? | criticality and dependency map |
| **C — Compensating control** | What can reduce exposure before final remediation? | tested mitigation and owner |
| **T — Triage and threat evidence** | Is ransomware use known or forensic triage required? | threat and evidence-preservation decision |
| **8 — Eight-point release check** | Are change, backup, test, rollback, monitoring, evidence, owner and deadline ready? | approved change record |
| **Closure** | Did remediation work and is residual risk accepted? | scan, version, log or exception proof |

The mnemonic deliberately begins with applicability. A ticket without an asset is not yet an operational decision. It then preserves CISA's due date instead of replacing it with a generic severity rule.

## Worked queue example

Suppose a new KEV affects a remote-management product. The organization discovers twelve installations: two internet-facing production servers, six internal servers, three disabled test instances and one unsupported appliance at a remote site.

A weak response creates twelve identical “critical” tickets. A stronger KEV-ACT-8 response verifies version and exposure, then creates three execution paths.

The two internet-facing systems enter immediate containment and forensic review because they are reachable and support privileged access. Logs and relevant volatile evidence are preserved according to incident policy before disruptive changes. The six internal systems receive a tested vendor remediation inside the assigned window, with network exposure confirmed and monitored. The disabled test instances are verified as non-running, patched or removed, and closed with evidence. The unsupported appliance becomes an explicit discontinue, isolate or exception decision owned by the business service manager.

The example does not lower urgency. It makes urgency executable. Every item has an asset, owner, control, deadline, evidence route and closure test.

## A vulnerability operations dashboard

Avoid a single count of “open KEVs.” Use a small portfolio of measures:

- new catalogue items awaiting applicability review;
- confirmed affected assets by due-window band;
- exposed affected assets with no tested mitigation;
- known-ransomware items by business service;
- forensic-triage items with evidence decision recorded;
- overdue items with accountable exception owner;
- remediated items awaiting validation;
- unsupported products requiring retirement decision.

Measure median time from catalogue addition to applicability decision separately from time to technical remediation. This reveals whether the bottleneck is inventory, ownership, testing, change capacity or vendor dependency.

## What students can build from the findings

A student does not need access to confidential infrastructure to demonstrate the workflow. Use a fictional company and public KEV records to build a portfolio case:

1. select ten records across different vendors, due windows and ransomware fields;
2. create a simulated asset inventory with clearly labelled assumptions;
3. map applicability and exposure;
4. build a KEV-ACT-8 queue;
5. write one forensic-triage escalation;
6. create a dashboard and an executive exception brief;
7. explain which evidence would change each decision.

The artifact should never claim that the student scanned a real organization. Its value is the decision logic, source discipline and control evidence.

## Limitations

This report is a dated census of CISA KEV version 2026.09.11, not a live feed. CISA can add or revise records after the download. The catalogue covers vulnerabilities CISA recognizes as exploited in the wild; it is not a complete inventory of every vulnerability, threat, product or incident.

Vendor and product names are preserved as published. We did not consolidate acquisitions, aliases or product families. Counts are influenced by installed base, disclosure and research attention and must not be interpreted as vendor quality rankings.

The remediation window is a difference between two catalogue dates. It does not measure how long a private organization actually took to remediate, when exploitation began or how difficult remediation was. Historical windows may reflect different directive rules.

“Known” ransomware use is a published flag; “Unknown” is not proof of no ransomware use. Forensic-triage analysis is descriptive and should be interpreted with current CISA implementation guidance. CWE assignments are multi-response and incomplete for some records.

The report does not use CVSS, EPSS, asset exposure, business impact, compensating controls or incident data. It cannot determine an organization's priority without those inputs. No causal or predictive claim is made.

## Reproducibility and integrity

The archival package contains the searchable PDF, source JSON as downloaded, an analysis-ready CSV, summary tables, machine-readable results, analysis code and a method note. The code records inclusion, date calculations, exact-string vendor grouping, multi-response CWE counting and descriptive bands.

CISA data are U.S. government public information, subject to the notices on the source site. External advisory links remain with their source organizations. MTF Institute performed the transformation, calculations and practical framework. CISA and the named vendors have not approved or endorsed this interpretation.

AI is not an author or evidence source. The named human reviewer checked the source identity, complete-record inclusion, calculations, bounded claims, limitations and practical application. The report contains no personal data and no exploit instructions.

## Learning pathway

Readers who want to practise governance, risk, control evidence, remediation and management reporting can explore MTF Institute's [Cybersecurity GRC Analyst: Governance, Risk and Compliance Operations](https://mtfinstitute.com/programs/cybersecurity-grc-analyst-governance-risk-compliance-operations/#enroll). It is online professional, non-degree education. Completion does not confer a security licence, replace vendor or CISA guidance, or guarantee employment or risk outcomes.

## Conclusion

CISA KEV is most useful when a team treats it as exploitation evidence inside an asset-aware decision system. The 1,709-record snapshot shows that most assigned windows cluster around three weeks, but short-window and long-tail cases are material. Ransomware and forensic-triage fields add distinct response questions. Vendor concentration creates ecosystem workload, while product diversity prevents a one-size-fits-all patch factory.

The practical answer is not “patch every KEV in the same way.” It is “verify applicability quickly, preserve the record-specific deadline, add exposure and business context, protect forensic evidence when required, execute a tested control and close with proof.”

## Sources

- [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [CISA KEV JSON feed](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)
- [CISA Binding Operational Directive 22-01](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities)
- [CISA Binding Operational Directive 26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)
- [MITRE Common Weakness Enumeration](https://cwe.mitre.org/)



## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/cisa-kev-1709-vulnerabilities-remediation-ransomware-forensic-triage-september-2026/