On October 11, 2026, the Cybersecurity and Infrastructure Security Agency added seven more flaws to its Known Exploited Vulnerabilities catalog, pushing the list past 1,739 entries. Three days earlier, five of those additions traced back to a China-linked group called Flax Typhoon, which had been quietly exploiting bugs dating back to 2015. None of this happened because the vulnerabilities suddenly got more severe. Their CVSS scores never changed. What changed is that someone confirmed attackers were already inside, using them.
That gap between “this looks dangerous on paper” and “this is actively being exploited right now” is the entire reason security teams argue about CVSS score vs CISA KEV. One is a 25-year-old severity scale built by committee. The other is a short, blunt government list updated almost daily. Teams that lean on only one of them end up patching the wrong things at the wrong time, and in 2026 that mistake is measurably more expensive than it used to be. This comparison, part of our ongoing security coverage, breaks down how each system works, what the current data says about their accuracy, and how to build a prioritization workflow that uses both without drowning your patch queue.
What Is CVSS? Severity Scoring, Not Risk Scoring
The Common Vulnerability Scoring System is maintained by FIRST.org, the same nonprofit that oversees EPSS. CVSS assigns every cataloged flaw a number from 0.0 to 10.0 based on technical factors: how the bug is reached (network, local, physical), how complex the attack is, whether privileges are required, and what breaks once it’s triggered (confidentiality, integrity, availability). The current versions in active use are CVSS v3.1, still the most widely adopted, and CVSS v4.0, which added supplemental metrics for safety and automation but hasn’t fully displaced v3.1 in most scanners yet.
Here’s the part that trips up a lot of teams building SLAs: a CVSS score measures how bad a vulnerability could be if exploited, not whether anyone is actually exploiting it. FIRST’s own Risk-Based Prioritization project is explicit about this limitation. As that project puts it, “CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.” That’s not a minor caveat. It’s the reason a huge share of vulnerability management programs built entirely around “patch everything above 7.0” burn through engineering hours on bugs nobody has ever tried to exploit, while older, moderately-scored bugs sit unpatched for years.
CVSS also doesn’t know anything about your environment. A 9.8 on an internet-facing FortiMail appliance and a 9.8 on an air-gapped lab server get the identical number, even though the real-world risk isn’t close. That blind spot is exactly what the next two frameworks exist to fill.
CVSS v2 vs v3.1 vs v4.0: Why Version Matters
CVSS has gone through four major revisions since 2005, and the version in use changes what a score actually means. CVSS v2, retired for new scoring but still visible on legacy CVE records, used a cruder 0-to-10 scale without a clean severity-tier mapping. CVSS v3.0 and the subsequent v3.1 refinement, released in 2019, added the Scope metric to capture when a flaw in one component lets an attacker escalate into a completely different one, which is common in container and API-gateway bugs. CVSS v4.0, finalized in late 2023, is the current standard but still trails v3.1 in real-world adoption, since most scanners, ticketing integrations, and CVE feeds default to whichever version a vendor’s advisory happened to publish first. The practical result is that a security team comparing two “critical” vulnerabilities might actually be comparing a v3.1 score against a v4.0 score without realizing the scales aren’t perfectly interchangeable.
What Is the CISA KEV Catalog?
The CISA Known Exploited Vulnerabilities catalog launched in November 2021 with a much narrower question than CVSS asks: has this specific CVE been confirmed as actively exploited in the wild? If yes, it goes on the list. If no, it doesn’t, regardless of how frightening its severity score looks. As of October 11, 2026, independent KEV trackers put the catalog at 1,739 entries, with 28 new CVEs added in just the preceding 30 days.
Federal civilian agencies are required to patch KEV-listed flaws by CISA’s published deadlines under Binding Operational Directive 22-01. Private organizations have no such legal obligation, but most serious vulnerability management programs now treat the catalog as a de facto mandatory list anyway, since it’s the clearest public signal that a bug has moved from theoretical to weaponized. The October 2026 additions illustrate the point well. CISA added Fortinet FortiMail’s CVE-2026-104286, a CVSS 9.8 path-traversal flaw letting unauthenticated attackers write arbitrary files, with a remediation deadline of October 3, 2026. Days later it added Citrix NetScaler ADC and Gateway’s CVE-2026-88779, an 8.7-rated memory-overflow bug, with a deadline of October 7.
What makes KEV genuinely different from a severity list is what else landed in that same October batch: CVE-2015-3306 in ProFTPD, a file-handling flaw from 2015 carrying a CVSS score of 10.0, and CVE-2021-3199 in ONLYOFFICE Docs, rated 9.8. Both had sat in the public record for years with top-tier severity scores and comparatively little urgency attached to them, until Flax Typhoon started using them against real targets. The lesson isn’t that CVSS failed here. The scores were accurate. The lesson is that a severity number alone, without exploitation evidence, doesn’t tell a security team which decade-old bug is about to become this week’s emergency.
Who Actually Has to Comply With KEV Deadlines
The legal reach of BOD 22-01 stops at federal civilian executive branch agencies. State and local governments, universities, and private companies are outside its scope, which surprises plenty of security leaders who assume KEV carries some broader regulatory weight. In practice, three forces pull private organizations toward KEV compliance anyway. Cyber insurance underwriters increasingly ask whether a company tracks and remediates KEV-listed vulnerabilities as part of renewal questionnaires. Government contractors working with federal civilian agencies often have KEV remediation written into contract language, even if the contractor itself isn’t bound by the directive directly. And incident response firms, when called in after a breach, routinely check whether the exploited CVE was already KEV-listed at the time of the attack, since that timeline becomes relevant in post-incident liability discussions.
Where EPSS Fits: Predicting What Happens Next
Between a static severity score and a confirmed exploitation list sits the Exploit Prediction Scoring System, also run by FIRST.org. EPSS doesn’t wait for confirmation. It produces a daily, calibrated probability, between 0 and 1, that a given CVE will see exploitation activity in the next 30 days, based on a model trained across exploit code repositories, scanner telemetry, and dark web chatter. The EPSS project defines the condition it’s forecasting plainly: “A vulnerability under active exploitation is one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.”
EPSS v4, running on model version v2025.03.14, began publishing in March 2025 and remains the current release as of October 2026. FIRST’s own documentation notes the baseline exploitation rate across all scored CVEs sits around 2% to 3%, meaning the overwhelming majority of published vulnerabilities, including many with alarming CVSS scores, never get touched by an attacker. That’s the gap EPSS is built to close: it tells teams which of their unexploited-but-scary bugs are statistically likely to become tomorrow’s KEV entry, before CISA confirms it.
EPSS isn’t flawless as an early-warning system, though. According to CrowdStrike’s analysis of historical EPSS performance, only 19.9% of CVEs that eventually landed in the CISA KEV catalog had carried an EPSS score above 0.5 before that exploitation was confirmed, and just 8.3% had ever crossed 0.9. In plain terms, EPSS catches a meaningful slice of what later turns out to matter, but it misses the majority of eventual KEV entries before the fact. That’s not a reason to ignore it. It’s a reason to treat it as one input among three, not a crystal ball.
FIRST’s performance documentation measures EPSS against three yardsticks instead of one blended accuracy number: coverage, which is the share of eventually-exploited CVEs a given score threshold would have flagged, effort, which is how many vulnerabilities a team would need to review to hit that coverage, and efficiency, which FIRST treats as equivalent to precision, the fraction of flagged vulnerabilities that actually got exploited. That three-part framing matters because a single “accuracy” headline would hide an uncomfortable tradeoff: push the threshold low enough to catch more future KEV candidates, and the number of false positives a team has to review climbs fast. EPSS v3 reportedly improved predictive performance by 82% over its predecessor, according to CrowdStrike’s writeup of the model’s history, and EPSS v4 refined the underlying feature set further, but the coverage-versus-effort tradeoff hasn’t disappeared. It’s been narrowed.
CVSS vs CISA KEV vs EPSS: Full Specs Comparison
Laid side by side, the three frameworks answer three different questions, and none of them answers all three on its own. The table below lines up the dimensions that matter most for building an actual patch queue.
| Dimension | CVSS v3.1 / v4.0 | CISA KEV Catalog | EPSS v4 |
|---|---|---|---|
| Maintained by | FIRST.org | CISA (U.S. DHS) | FIRST.org |
| What it measures | Technical severity if exploited | Confirmed active exploitation | Probability of exploitation in 30 days |
| Output format | 0.0–10.0 numeric score | Binary: listed or not | 0–1 calibrated probability |
| Catalog size (Oct 2026) | Applies to tens of thousands of CVEs disclosed yearly | 1,739 entries | Score for nearly every published CVE |
| Update frequency | Set once per CVE, versioned over time | Several additions most weeks | Recalculated daily |
| Considers real-world exploitation | No | Yes, by definition | Statistically, not confirmed |
| Considers asset exposure/context | No | No, left to the organization | No |
| Federal remediation mandate | None | Yes, BOD 22-01 for civilian agencies | None |
| Public access | Free, via NVD and vendor advisories | Free CSV/JSON feed from cisa.gov | Free daily CSV from first.org |
| First released | 2005 (v1); current v4.0 in 2023 | November 2021 | 2019 (v1); current v4 in March 2025 |
| Typical role in workflow | Technical impact triage | “Patch this first” hard gate | Early-warning forecast |
| Cost to adopt | $0 | $0 | $0 |
How a CVSS Score Actually Gets Calculated
A CVSS score starts with the Base metric group, which is fixed at disclosure and almost never revised: attack vector, attack complexity, privileges required, user interaction, and the confidentiality/integrity/availability impact triad. Vendors and the National Vulnerability Database then publish this Base score as the headline number most dashboards display.
Two optional layers sit on top of it. Temporal metrics adjust the score based on exploit maturity and remediation availability, functioning as CVSS’s closest built-in analog to KEV, but almost nobody scores this layer consistently since it requires manual upkeep. Environmental metrics let an organization re-weight the score for its own asset criticality and compensating controls. In practice, most teams never touch either layer. They pull the Base score straight from the vendor advisory and build ticket priority around that single number, which is precisely how a 9.8 on an exposed mail gateway and a 9.8 on a dev sandbox end up in the same sprint.
This is also where CVSS v4.0 tried to improve things, adding Supplemental metrics for Safety, Automatable, Recovery, and Provider/Consumer Urgency. Adoption has been slow. Most vulnerability scanners, ticketing integrations, and compliance frameworks still default to v3.1, so a security team evaluating any given CVSS 10.0-rated flaw in 2026 is most likely looking at a Base-only v3.1 number, stripped of the context that would actually tell them how urgent it is.
How a Vulnerability Actually Lands in the KEV Catalog
CISA’s bar for adding a CVE to KEV is narrower than most people assume. The agency requires reliable evidence of active exploitation, a clear CVE identifier already in the national vulnerability record, and a documented remediation path, whether that’s a vendor patch, a mitigation, or an end-of-life notice. CISA has said plainly that organizations should treat the catalog as “an input to their vulnerability management prioritization framework,” not a complete one on its own.
Evidence typically comes from one of a few channels: incident response engagements where responders find a CVE actively used in a breach, threat intelligence from vendors like Mandiant, CrowdStrike, or Qualys flagging exploitation in telemetry, or government partners sharing classified or open-source reporting. The Flax Typhoon additions from early October 2026 came through exactly this path. Vendors and government partners observed the China-linked actor abusing five specific CVEs, including the 2015-era ProFTPD bug and a 2021 ONLYOFFICE flaw, and CISA added all five to the catalog on back-to-back days once exploitation was confirmed.
Once a CVE is listed, federal civilian agencies get a remediation deadline, usually two to three weeks for critical, internet-facing flaws, though CISA has shortened that window in several 2026 additions, including the three-day turnaround on FortiMail’s CVE-2026-104286. Private-sector teams don’t get a legal deadline, but security leaders increasingly borrow CISA’s timelines as their own internal SLA, since the catalog has become the most trusted public signal that exploitation is confirmed rather than theoretical.
Benchmarks: What the 2025-2026 Data Actually Shows
Numbers from three independent sources paint a consistent, uncomfortable picture: the window between disclosure and exploitation has collapsed, and severity scores alone aren’t predicting where attackers strike first.
| Metric | Figure | Source |
|---|---|---|
| Mean Time-to-Exploit, 2025 | -7 days (exploitation observed before public disclosure, on average) | Mandiant M-Trends 2026, cited via Qualys TRU |
| Mean Time-to-Exploit, 2024 | -1 day | Mandiant M-Trends 2026 via Qualys TRU |
| New vulnerabilities disclosed in 2025 | 48,172 | Qualys TRU |
| Share remotely exploitable, weaponized, with working PoC | 357 vulnerabilities (0.74%) | Qualys TRU |
| Median time from CVE publication to KEV listing, 2025 | 5.0 days (down from 8.5 days in 2024) | Rapid7 |
| CISA KEV catalog size, October 11, 2026 | 1,739 entries | Independent KEV trackers (immunitysec.com, thrunt.me) |
| New KEV additions in the trailing 30 days | 28 CVEs | isMalicious KEV tracker |
| Breaches initiated via vulnerability exploitation, 2026 | 31%, up from 20% a year earlier | Verizon 2026 Data Breach Investigations Report |
| Eventual KEV entries with EPSS above 0.5 pre-exploitation | 19.9% | CrowdStrike EPSS analysis |
| Eventual KEV entries with EPSS above 0.9 pre-exploitation | 8.3% | CrowdStrike EPSS analysis |
Read together, these numbers argue against either extreme. A mean time-to-exploit of negative seven days means attackers are, on average, already weaponizing a flaw before it’s even publicly disclosed, usually through supply-chain leaks, dark web trading, or zero-day discovery. Waiting for a CVSS score to get published, let alone waiting for a quarterly patch cycle, puts a team structurally behind. But EPSS catching only one in five future KEV entries at a meaningful confidence level before the fact means predictive scoring alone isn’t a safety net either. The 31% jump in breaches tracing back to vulnerability exploitation, from Verizon’s 2026 DBIR, is the real-world cost of getting this sequencing wrong.
The 48,172 new vulnerabilities disclosed in 2025, against just 357 assessed as remotely exploitable, weaponized, and backed by working proof-of-concept code, also reframes the scale problem differently than most teams assume. The fear that a severity-score-only approach misses “most” dangerous bugs isn’t quite right. Fewer than 1% of annual disclosures reach that highest-danger tier. The real failure mode is that CVSS alone can’t tell you which 0.74% that is in advance, and by the time KEV or incident response confirms it, the median five-day window to catalog inclusion has often already closed on an unpatched system.
Five Real-World Examples From the October 2026 KEV Additions
The clearest way to see how these three frameworks diverge is to walk through specific CVEs that moved through the system in the same two-week window.
- CVE-2026-104286 (Fortinet FortiMail), CVSS 9.8, a path traversal flaw allowing unauthenticated attackers to write arbitrary files. High severity and confirmed exploitation agreed here. Security Affairs reported that CISA gave federal agencies until October 3, 2026 to patch, one of the tightest windows of the month.
- CVE-2026-88779 (Citrix NetScaler ADC/Gateway), CVSS 8.7, a memory-overflow condition. CISA’s October 4 addition and October 7 deadline show the catalog moving almost as fast as the exploitation itself, something a standard quarterly patch cycle built around severity scores alone would never match.
- CVE-2015-3306 (ProFTPD), CVSS 10.0, but disclosed in 2015. Eleven years of dormancy, then sudden active exploitation by Flax Typhoon in 2026. This is the strongest argument against “patch by age” heuristics: a bug’s severity score doesn’t decay, but attention to it does, and attackers know that.
- CVE-2021-3199 (ONLYOFFICE Docs), CVSS 9.8, a path-traversal weakness capable of remote code execution. Added to KEV alongside the ProFTPD flaw as part of the same Flax Typhoon campaign, reinforcing that a single threat actor often chains old, forgotten, high-severity bugs rather than hunting for brand-new ones.
- CVE-2023-22894 (Strapi), CVSS 7.2, the lowest score in the October Flax Typhoon batch. A pure CVSS-threshold policy set at “patch anything above 8” would have left this one in the backlog indefinitely, right up until it became part of an active intrusion chain exposing admin-panel user data.
- Apache Struts and ISC BIND entries, added to KEV in the same October 2026 window, expanding the pattern beyond network edge appliances into core web-application frameworks and DNS infrastructure, categories that security teams often treat as lower patch priority than internet-facing gateways.
Every one of these had a CVSS score available well before CISA’s KEV action. In most cases the score was already high enough to justify urgency on its own. The Strapi case is the outlier that matters most: a 7.2 is comfortably “High” under CVSS but far enough from the 9-and-10 cluster that many teams’ internal SLAs would have deprioritized it, right until active exploitation proved otherwise. Put the six examples side by side and a pattern emerges: CISA’s KEV additions in October 2026 weren’t dominated by brand-new zero-days. They skewed toward vulnerabilities that had already been public, sometimes for years, with scores that never needed revising. What changed wasn’t the math. It was the evidence.
Pricing and Cost: What Each Framework Actually Costs to Run
All three frameworks discussed here are free, open, and publicly published. CVSS scores ship with every CVE record on the National Vulnerability Database at no cost. The CISA KEV catalog is a free CSV and JSON feed anyone can pull into a script or a SOAR pipeline. EPSS publishes its daily scored dataset from first.org at no charge. The real cost shows up one layer up, in the commercial platforms organizations use to operationalize all three signals at scale.
| Framework / Platform | Maintainer | Access | List Price | Deployment Model |
|---|---|---|---|---|
| CVSS v3.1 / v4.0 | FIRST.org | Free, open specification | $0 | Embedded in NVD, scanners, ticketing tools |
| CISA KEV Catalog | CISA (U.S. DHS) | Free public CSV/JSON feed | $0 | Pulled via API into SOAR/VM tools |
| EPSS v4 | FIRST.org | Free daily score feed | $0 | Integrated into risk-based VM platforms |
| Tenable Vulnerability Management | Tenable | Commercial SaaS | Custom quote, asset-based | Cloud-hosted scanning + agents |
| Qualys VMDR | Qualys | Commercial | Custom quote, asset-based | SaaS and on-prem hybrid |
| Rapid7 InsightVM | Rapid7 | Commercial | Custom quote, asset-based | SaaS console with on-prem agents |
| CrowdStrike Falcon Spotlight | CrowdStrike | Commercial, bundled Falcon module | Custom quote | Cloud-native, agent-based |
| Wiz | Wiz | Commercial | Custom quote, workload-based | Agentless cloud scanning |
None of the major commercial vulnerability management vendors publish flat list pricing. All five platforms above sell through sales-quoted contracts scaled to asset count, cloud workload volume, or user seats, which means the real decision most teams face isn’t “which free framework,” but which paid platform ingests CVSS, KEV, and EPSS cleanly enough to act on all three without three separate dashboards.
Pros and Cons of Each Prioritization Model
CVSS’s strength is universality. Every CVE gets one, it’s calculated the same way regardless of vendor, and it plugs directly into compliance frameworks like PCI DSS and FedRAMP that reference specific score thresholds. Its weakness is exactly what FIRST warns about: it says nothing about whether anyone is actually exploiting the bug, so teams that patch strictly by score end up firefighting low-scored flaws that turn into breaches while high-scored, unexploited flaws sit untouched in a queue.
KEV’s strength is precision. Every single entry represents confirmed, real exploitation, so there’s essentially no false-positive patching driven by the catalog itself. Its weakness is coverage and timing: at 1,739 entries against tens of thousands of CVEs disclosed annually, KEV is deliberately narrow, and a flaw doesn’t appear until after someone has already been attacked with it. It’s a reactive signal by design, not a forecast.
EPSS’s strength is that it tries to close that timing gap, scoring every CVE daily with a forward-looking probability instead of waiting for confirmed harm. Its weakness, per CrowdStrike’s own analysis, is recall: fewer than one in five eventual KEV entries carried a high EPSS score beforehand, so treating EPSS as a complete substitute for KEV or CVSS leaves real gaps. Used together, the three cover each other’s blind spots far better than any one alone.
There’s a cost dimension to these tradeoffs too, separate from the dollar figures covered later. CVSS-only triage is the cheapest to run operationally, since it requires no external feed integration beyond what a scanner already reports, but it’s the most expensive in wasted engineering time, because teams end up patching a long tail of unexploited high scores. KEV-only triage is cheap to integrate and extremely efficient per patch cycle, but it leaves a coverage gap for genuinely dangerous CVEs that haven’t been confirmed exploited yet. EPSS sits in between: it takes more engineering effort to wire into a ticketing system’s scoring logic, but it narrows that coverage gap meaningfully for teams willing to tolerate its lower recall.
Use Cases: Which Framework Fits Which Team
The right mix depends heavily on team size, regulatory exposure, and how much automation is already in place.
- Federal agencies and contractors have no choice: BOD 22-01 makes KEV compliance mandatory, so it has to sit at the top of the workflow regardless of what other scoring a team prefers internally.
- Small security teams with no dedicated vuln management headcount get the most value from leaning on KEV first, since its small size and binary nature (“is it listed or not”) make triage fast without needing a dedicated analyst to interpret probability scores.
- Mature programs with risk-based VM tooling already deployed (Tenable, Qualys, Rapid7) should layer EPSS on top of KEV to catch the roughly four out of five future KEV candidates that EPSS can flag early, even imperfectly.
- Compliance-driven environments bound by PCI DSS, HIPAA, or FedRAMP language that references specific CVSS thresholds still need CVSS as the documented baseline, even if it’s not driving day-to-day triage order.
- Serverless and API-heavy architectures, the kind exposed by flaws like the recent AWS Lambda IAM bypass and a separate GitLab AI Gateway vulnerability, need KEV and EPSS checks run against third-party and managed-service CVEs just as rigorously as against self-hosted software, since the exploitation evidence behind a KEV listing doesn’t care who operates the underlying infrastructure.
- Internet-facing infrastructure teams, running edge appliances like the FortiMail and Citrix NetScaler systems hit in October 2026, should treat any KEV addition touching their stack as an automatic, same-week action item, independent of its CVSS number.
- Cloud-native and SaaS companies scanning ephemeral workloads benefit most from EPSS’s daily refresh cycle, since static annual CVSS reviews can’t keep pace with infrastructure that gets rebuilt weekly.
- Managed security service providers juggling dozens of client environments typically standardize on KEV as the universal override across every client, since it’s the one signal that doesn’t require per-client tuning to stay meaningful.
- Legacy software maintainers and long-tail enterprise IT shops, the kind running decade-old appliances similar to the 2015 ProFTPD and 2021 ONLYOFFICE cases, should run a standing KEV match against their full asset inventory on a recurring basis rather than only checking newly disclosed CVEs, since old, previously ignored bugs are exactly what resurfaces in these catalogs.
Migration Guide: From CVSS-Only to a Risk-Based Workflow
Teams still running a pure “patch anything above CVSS 7” policy can move to a layered model without a full tooling overhaul. The shift isn’t about ripping out a scanner or signing a new enterprise contract. It’s about changing which signal decides what gets worked on first, and building the override logic so that decision happens automatically instead of depending on an analyst remembering to check a second source. Here’s the practical sequence.
- Pull the CISA KEV feed into your ticketing system first. It’s a free CSV/JSON download, and matching it against your asset inventory by CVE ID is a same-day scripting task, not a procurement cycle.
- Set KEV matches as an automatic Severity-1 override, regardless of the underlying CVSS score, so a KEV hit always jumps the queue ahead of score-based sorting.
- Add the EPSS daily feed as a secondary signal for everything not yet in KEV. Flag anything above roughly 0.5 probability for accelerated review, consistent with how the EPSS project recommends using the score as a triage filter rather than a hard gate.
- Keep CVSS as your baseline documentation layer, since audit frameworks, cyber insurance questionnaires, and compliance reporting still expect it. Don’t rip it out. Just stop letting it be the only sort key.
- Layer in environmental context manually for anything internet-facing or holding regulated data, since none of the three frameworks natively weighs asset exposure.
- Re-run the match against KEV weekly, not monthly. With a median publication-to-KEV-listing time of 5.0 days in 2025 per Rapid7, a monthly sync misses real urgency windows.
- Document the decision logic: KEV overrides CVSS, EPSS accelerates review, CVSS sets baseline SLA, so new team members and auditors can follow the reasoning without guessing.
None of this requires replacing an existing scanner or vulnerability management contract. Tenable, Qualys VMDR, Rapid7 InsightVM, and CrowdStrike Falcon Spotlight all already ingest KEV and EPSS data natively. The migration work is almost entirely about changing the sort order and override rules, not buying new software.
What Security Practitioners Say About the Conflict
Joye Purser, Global Field CISO at Cohesity, has described directly how to sequence these signals when they disagree. In comments to Help Net Security, Purser said: “An actively exploited vulnerability, as indicated by KEV, would be the highest priority, particularly if it affects an internet-exposed or business-critical asset.” That’s the override rule in practice: confirmed exploitation plus exposure beats everything else on the list.
Purser continued by laying out what comes next once KEV is checked: “After that, I would assess exploit likelihood using EPSS, followed by CVSS, to understand the potential technical impact.” That ordering, KEV first, then EPSS, then CVSS, mirrors almost exactly the migration sequence described above, and it comes from someone running prioritization decisions at enterprise scale rather than a theoretical framework comparison.
FIRST’s own EPSS maintainers frame the underlying exploitation condition in careful, evidentiary terms, writing that active exploitation requires “reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.” That precision is deliberate. It’s what keeps the KEV catalog small and trustworthy instead of bloated with speculative entries, and it’s why security teams treat a KEV listing as close to ground truth.
The Verdict: What the Data Actually Supports
Neither CVSS nor CISA KEV wins this comparison outright, because they’re not competing for the same job. CVSS answers “how bad could this be.” KEV answers “is this actually happening.” EPSS tries to answer “is this about to happen,” and does so with real but limited accuracy, catching under 20% of future KEV entries at high confidence per CrowdStrike’s analysis.
The data points toward a clear operational order, though. With mean time-to-exploit sitting at negative seven days in 2025 and median publication-to-KEV time down to five days, the organizations getting breached are overwhelmingly the ones still sorting their patch queue by CVSS score alone. A 1,739-entry KEV catalog is small enough to check against any asset inventory in minutes, and a confirmed-exploitation hit should override a severity number every time. CVSS still has a job: documentation, compliance, and baseline SLA-setting for the roughly 98% of CVEs that never reach KEV. But as a sole prioritization signal in 2026, it’s the weakest of the three, and the Flax Typhoon campaign’s reuse of 2015- and 2021-era bugs is proof that age and a stale score are exactly the conditions attackers look for.
For a team that can only adopt one new habit this quarter, the highest-leverage move is the cheapest one: pull the free KEV feed and match it against the asset inventory weekly. It costs nothing, takes a day to script, and would have caught every one of the six examples covered above before CISA’s own deadline passed. EPSS is the natural second step once that foundation is in place, not a replacement for it. CVSS, for all its limitations as a standalone trigger, remains the only one of the three that every compliance framework, cyber insurance form, and vendor advisory already speaks fluently, which is reason enough to keep it in the stack rather than retire it.
Frequently Asked Questions
Is a CVSS score the same thing as risk?
No. CVSS measures technical severity if a vulnerability is exploited. It doesn’t factor in whether exploitation is actually happening or how exposed a specific asset is, which is why FIRST’s own guidance warns against using the Base score alone to assess risk.
How many vulnerabilities are currently in the CISA KEV catalog?
Independent KEV trackers put the catalog at 1,739 entries as of October 11, 2026, with 28 new CVEs added in the preceding 30 days.
Does a low CVSS score mean a vulnerability can be ignored?
No. The October 2026 Flax Typhoon additions included CVE-2023-22894 in Strapi at a comparatively modest 7.2, which still became part of an active exploitation chain. Score and exploitation risk aren’t the same thing.
What’s the difference between EPSS and CISA KEV?
KEV lists vulnerabilities with confirmed, evidenced active exploitation. EPSS forecasts the probability that a vulnerability will be exploited in the next 30 days, before that confirmation exists. KEV is retrospective and binary. EPSS is predictive and probabilistic, and the two are designed to complement rather than replace each other.
Is the CISA KEV catalog free to use?
Yes. CISA publishes it as a free CSV and JSON feed at cisa.gov, and any organization can pull it into internal tooling without licensing cost.
Are federal agencies required to patch every CVSS-critical vulnerability?
No. Binding Operational Directive 22-01 specifically requires federal civilian agencies to remediate CISA KEV-listed vulnerabilities by set deadlines. It does not mandate action on every high-CVSS CVE, only confirmed KEV entries.
Why did an 11-year-old vulnerability like CVE-2015-3306 suddenly matter again in 2026?
Age doesn’t reduce a CVSS score, and attackers increasingly target older, high-severity bugs that organizations deprioritized over time. CISA added the 2015 ProFTPD flaw to KEV in October 2026 after confirming Flax Typhoon was actively exploiting it, more than a decade after its original disclosure.
