The future of cybersecurity: predicting which vulnerabilities to patch first

Why predicting threats now means ranking vulnerabilities

The volume alone rules out patching everything at once. As of September 18, 2026, more than 67,000 new CVEs had been published that year, and NIST's National Vulnerability Database reported a 263% rise in CVE submissions between 2020 and 2025, according to CISA's Quality Era white paper.

Most of those vulnerabilities will never be used in an attack. The team behind EPSS observes exploitation activity for roughly 1.5% to 3% of published vulnerabilities in any 30-day window, and its FAQ notes that CISA's KEV catalogue lists about 0.5% of published CVEs. The window for acting is also shrinking: BOD 26-04 states that attackers' use of AI may further narrow the time defenders have between a patch's release and exploitation.

So the useful prediction is narrow and concrete: of the vulnerabilities present in your systems, which will be exploited soon, and which of those can an attacker reach? Detecting an attack already in progress, with anomaly detection or behavioural analytics, is a different job and a different set of tools.

Why CVSS severity alone is a poor patch priority

The Common Vulnerability Scoring System, maintained by FIRST, rates how severe a vulnerability is on a scale of 0.0 to 10.0. CVSS v4.0 was published on November 1, 2023, and has four metric groups:

• Base: the intrinsic characteristics of the flaw, constant over time, assuming the reasonable worst-case impact across deployments.
• Threat: one metric, Exploit Maturity, with the values Attacked, POC (proof-of-concept), Unreported and Not Defined. Not Defined is scored as Attacked, the worst case.
• Environmental: your mitigations and how important the vulnerable system is to you.
• Supplemental: extra context that does not change the score, such as Automatable (can an attacker automate exploitation across many targets?) and Recovery.

Version 4.0 also names each score by the groups used: CVSS-B for Base only, CVSS-BT with Threat, CVSS-BE with Environmental, CVSS-BTE with both. The catch is in the same specification: product maintainers and the NVD typically publish only the Base score, CVSS-B, and adding Threat and Environmental metrics is left to you. Unless your tools add them, the number on a scanner report is a Base score: a pure severity rating. FIRST's own CVSS v4.0 FAQ states that Base scores are not a measure of risk and should not be used on their own for patch prioritization.

The practical problem is volume. FIRST's current EPSS guidance counts about 61,000 CVEs published over the previous 12 months, just over 10% of them rated Critical, while High and above covers roughly the top 48% of all published vulnerabilities. A rule of "patch every Critical and High first" therefore puts about half of all CVEs at the front of the queue. The EPSS FAQ goes further: it says CVSS and EPSS scores are empirically uncorrelated, and that high severity scores are only slightly better than random at predicting exploitation activity.

Severity still matters. It tells you how much damage a successful exploit can do, which is the other half of risk. It just cannot tell you whether anyone will try.

How EPSS predicts exploitation

The Exploit Prediction Scoring System estimates the probability, from 0 to 1, that exploitation activity for a given CVE will be observed in the next 30 days. It is a machine-learning model maintained by the EPSS Special Interest Group at FIRST, with scores generated by Empirical Security and published free every day for every scored CVE, typically shortly after 13:30 UTC. Its predictions are published in advance and then measured against the exploitation activity observed in the following 30 days.

What the model looks at

FIRST's description of the model lists about 2,850 features per vulnerability per day, in several groups:

• Exploit code and offensive tooling: whether exploit code exists, where it was published, and whether it has been built into tools such as Metasploit modules or Nuclei templates.
• Chatter: which security sites, vendor feeds and advisories mention the CVE, and how recently.
• Vulnerability characteristics: the individual CVSS metrics (not the score), tags derived from the description such as remote code execution, and the vendor.
• Age and references: older vulnerabilities are exploited at higher rates, and reference volume tracks how much attention a CVE has drawn.

The outcome it learns from is exploitation activity reported by nearly a dozen data partners: intrusion detection and prevention sensors, honeypots, endpoint malware telemetry and threat intelligence feeds. The model is an ensemble of gradient-boosted decision trees built with XGBoost, trained on 12 months of history, then calibrated so that a score of 0.05 really corresponds to about a 5% observed rate. The 30-day window was chosen to match the monthly patch cycle most teams already run.

The model changes over time. EPSS version 4 started publishing on March 17, 2025, and version 5 (model v2026.06.15) on June 15, 2026. Each new version shifts the scores on the day it starts, so a trend line that crosses one of those dates reflects the methodology as well as the vulnerability.

How to read the probability and the percentile

Every score comes with two numbers:

Because exploitation is rare, most probabilities look small, and the percentile gives the context. FIRST recommends reporting the probability first, with the percentile beside it, for example "15.3% (92nd)".

There is no universal threshold. A cut-off of 10% is often quoted, but FIRST says it carries no special authority. A better starting point is capacity: FIRST estimates that the 90th percentile, a probability of about 4% or more, selects roughly as many CVEs as a CVSS Critical filter, and a probability of about 0.8% matches the size of a "High and above" filter. Start there, then adjust to the volume your team can actually fix.

Pulling scores is one command. The API is meant for lookups of one CVE or a small batch; the daily CSV file suits joining scores to a full scanner export:

# Current score and percentile for two CVEs
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-21762,CVE-2024-6387"

# Today's scores for every CVE (the first line names the model version)
curl -sL https://epss.empiricalsecurity.com/epss_scores-current.csv.gz | gunzip -c | head -3

Three limits are worth remembering. EPSS is a population-level estimate: it knows nothing about whether the software is present in your environment, whether an attacker can reach it, or what it would cost you. A low score is not a declaration of safety, only a lower probability. And the score is not a live attack feed: exploitation observed today trains the model but does not directly change tomorrow's score.

What CISA's KEV catalogue adds

Where EPSS is a forecast, the Known Exploited Vulnerabilities catalogue is a record. CISA adds a vulnerability only when three criteria are met:

1. It has a CVE ID.
2. There is reliable evidence of active exploitation in the wild. Attempted exploitation counts; scanning, security research and a published proof-of-concept do not.
3. There is a clear remediation action, such as a vendor update.

The catalogue is small. Catalogue version 2026.09.24 held 1,723 entries, and CISA marked 361 of them as known to be used in ransomware campaigns. It is published as JSON and CSV feeds, with email alerts for new entries.

It began with BOD 22-01, issued on November 3, 2021, which required US federal civilian agencies to fix listed vulnerabilities within two weeks, or six months for CVEs assigned before 2021. On June 10, 2026 CISA revoked that directive, together with BOD 19-02 on internet-accessible systems, and replaced both with BOD 26-04, which carries the catalogue and its criteria forward. The deadlines bind only federal civilian agencies, but CISA recommends that every organization build a requirement to address KEV entries immediately into its vulnerability management plan.

Taken together, the three signals answer different questions:

SSVC and BOD 26-04: from scores to patch deadlines

A score does not say what to do or by when; a decision tree does. Carnegie Mellon's Software Engineering Institute created Stakeholder-Specific Vulnerability Categorization (SSVC) with CISA in 2019, and CISA built its own tree in 2020. It walks five decision points (exploitation status, technical impact, automatable, mission prevalence and public well-being impact) to one of four outcomes:

• Track: no action now; fix within standard update timelines.
• Track*: as Track, but watch for changes.
• Attend: supervisors get involved; fix sooner than standard timelines.
• Act: leadership gets involved; fix as soon as possible.

You do not have to research every decision point yourself. Through its Vulnrichment program, announced on May 10, 2024, CISA adds its SSVC values to CVE records: exploitation (none, poc or active), automatable (yes or no) and technical impact (partial or total). Since June 17, 2026 the NVD also carries that SSVC data in its feeds and API, and since late August 2026 on its CVE pages.

BOD 26-04 turned this into a timetable. It asks four questions about each vulnerable asset: is it publicly exposed, is the CVE in KEV, can an adversary automate the exploit, and does exploitation give partial or total control? The answers map to a deadline in calendar days:

"Triage" means forensic triage: fixing the flaw and checking whether the system was already compromised. The clock starts when CISA adds the CVE to KEV or when the agency finds it on an asset, whichever comes first, and it moves as facts change: taking a system off the internet is a valid mitigation that lengthens its deadline, while a new KEV listing shortens it. CISA's implementation guidance explains the design choice: CVSS labels such as "critical" or "high" do not prescribe any action, so the directive replaces them with explicit timelines, and those timelines are maximums that an organization may shorten.

Exposure is the question only you can answer, and the worked example below shows how much it can reorder a list. The directive defines a publicly exposed asset as one reachable by unauthenticated or untrusted parties over a public network such as the internet, wherever it physically sits.

A worked example: four real CVEs, three different orders

Suppose a scan of a hypothetical 40-person company finds the four vulnerabilities below. They are real CVEs. The CVSS, KEV and CISA SSVC values come from the NVD records for CVE-2024-21762, CVE-2025-1909, CVE-2024-6387 and CVE-2024-38217 as of September 25, 2026, and the EPSS values from the EPSS API for September 24, 2026. Where each system sits is our assumption for the example.

Ranked three ways, the list comes out in three different orders:

What the comparison shows:

• CVSS alone puts an exploited flaw last. The Windows bypass is on every laptop and in KEV, yet its 5.4 sends it to the bottom. That 5.4 is Microsoft's own score; the NVD page shows no NIST assessment for it.
• EPSS alone would over-rank OpenSSH here. A 99.5% probability means exploitation activity is widely observed across the internet, but in this company sshd is reachable only through the VPN. The score is right about the world and silent about your network.
• A low EPSS is not a pass. The WordPress plugin scores 0.64%, but it sits on the public website, CISA rates it automatable with total control, and the directive gives it three days. Exposure and ease of attack outweigh the forecast.
• The directive's deadlines are ceilings. "Next upgrade" is the maximum for the internal OpenSSH server. With an EPSS in the top 1%, the policy below gives it 14 days, and patching sshd rarely takes long.

The same four findings produce a different plan in a company where sshd faces the internet or the website has no such plugin. That is the point: the scores are shared, the exposure is yours.

Threat intelligence feeds a small team can actually use

For a small team, threat intelligence does not need to mean a platform subscription. It means a few feeds that answer one question: is something we run being attacked? These cover most of it, and all are free:

• The KEV catalogue, by email alert or by pulling the JSON feed daily and matching it against your scanner output and asset list.
• EPSS scores, from the daily CSV, joined to your findings by CVE ID.
• Your vendors' security advisories for every product in the inventory: firewall, VPN, operating systems, hypervisor, CMS and plugins. They name the fixed versions, and they do not wait for a database to enrich the record.
• Your national CERT. The Canadian Centre for Cyber Security publishes alerts and advisories with a web feed; CISA and other national agencies do the same for their countries.
• Reports about your own networks. The Shadowserver Foundation sends free daily reports to network owners about exposed services and malicious activity seen from their address ranges.

As the team grows, two standards make feeds easier to automate. STIX and TAXII, maintained by OASIS, are the format and the transport protocol for exchanging machine-readable threat intelligence. MITRE ATT&CK is the knowledge base of adversary tactics and techniques, based on real-world observations, that lets you check whether your detections cover what attackers do after an exploit works. Indicator feeds of IP addresses, domains and file hashes help only if a firewall, EDR agent or SIEM consumes them automatically; they are not meant to be read by hand.

The order matters more than the tooling: build the asset inventory first, then subscribe to feeds for what is in it, then route every match to a ticket with an owner.

How healthy is the vulnerability data itself?

Every score above depends on a supply chain of vulnerability data, and since 2024 that chain has been under strain.

The NVD backlog. The NVD's own updates record a processing slowdown in spring and early summer 2024 and a significant backlog of unenriched CVEs from early 2024, while CVE submissions rose 32% that year. In April 2025 NIST marked unenriched CVEs published before 2018 as Deferred. On April 15, 2026 it moved to a risk-based model: CVEs in KEV (targeted within one business day), software used in the federal government and critical software under Executive Order 14028 are enriched first, and everything else is listed as lowest priority. Backlogged CVEs published before March 1, 2026 moved to "Not Scheduled", and NIST no longer routinely adds its own severity score when the CNA has provided one. Even published scores can be wrong: on April 28, 2026 NIST corrected about 4,500 records, 19% of those with a CVSS v4.0 score, whose numerical score had been calculated too high.

The CVE Program's contract scare. The CVE Program is sponsored by CISA and run by a federally funded research and development centre operated by MITRE. In April 2025 its contract came close to lapsing: CISA executed the contract's option period on April 15 to avoid any lapse in CVE services, and a week later described it as a contract administration issue rather than a funding shortfall. The CVE Foundation was formally launched on April 16, 2025 to work for the program's long-term stability and independence, and CISA's September 2026 white paper sets out a "Quality Era" of governance, infrastructure and data-quality work.

A European alternative. ENISA made the European Vulnerability Database (EUVD) operational on May 13, 2025, as the NIS2 Directive requires. It aggregates CVE data, vendor advisories, national CSIRT alerts and CISA's KEV catalogue, with dashboards for critical, exploited and EU-coordinated vulnerabilities; ENISA has also been a CVE Numbering Authority since January 2024.

The lesson for a small team: do not depend on one database. Take severity and affected versions from the vendor advisory, exploitation from KEV, likelihood from EPSS, and check which sources your scanner uses when a record arrives with no score.

A patch prioritization policy a small IT team can adopt

NIST's SP 800-40 Rev. 4 frames patching as preventive maintenance: a cost of doing business, not a project. The policy below uses the BOD 26-04 table as its ceiling and tightens it in two places a small team can afford. Write it down, and have the owner of the business sign it.

1. Keep an inventory. List every system with an owner and one tag: internet-facing or internal. Without it, the deadlines cannot be applied.
2. Scan on a schedule and after changes. Pull the KEV feed and EPSS scores daily and join them to the findings by CVE ID.
3. Use the BOD 26-04 table as your maximum deadlines, counted in calendar days from when the finding or the KEV listing appears, whichever is first. When a KEV flaw gives total control, check the system for signs of compromise as well as patching it.
4. Add two rules of your own. Anything at or above the 90th EPSS percentile gets 14 days at most, whatever the table allows. "Next upgrade" becomes "the next monthly patch cycle", so nothing waits for a rebuild that may never be scheduled.
5. Mitigate when you cannot patch in time. Disable the vulnerable feature, restrict access to it, or take the system off the internet, which lengthens its deadline under the table. Record every exception with an owner, a reason and a review date.
6. Retire what cannot be fixed. For end-of-life products, CISA's KEV guidance is to remove them from the network when they cannot be updated. Track end-of-life dates before they arrive.
7. Prove the fix. Re-scan after patching, close the finding only when the re-scan is clean, and track time to fix for each deadline band.
8. Review the policy each quarter, and after any incident, against what was actually exploited in that period.

If scanner output runs to hundreds of findings and nobody triages it, our security testing service runs scheduled external scans of websites, servers and cloud accounts, ranks findings with CVSS, EPSS and the CISA KEV catalogue, and closes each fix with a re-test. For websites, our hosting and maintenance service applies OS, CMS and plugin updates on a cadence, with out-of-cycle patching for critical CVEs. For the rest of the basics, see our cybersecurity checklist for small business and the website security checklist.