EPSS and KEV Patch Prioritization for the AI Stack: A Working Guide
CVSS severity alone tells you a vulnerability is bad, not whether it is being exploited. This guide shows how to combine the FIRST EPSS exploitation probability score with the CISA Known Exploited Vulnerabilities catalog to rank patch work across your AI inference stack, with a scoring rule, a worked example on real 2026 AI-tool CVEs, and an honest line on what patch prioritization does and does not cover.
A CVSS base score of 9.8 tells you a vulnerability is severe if exploited. It says nothing about whether anyone is exploiting it. That distinction is the whole reason patch queues built on CVSS alone drown teams: FIRST projects roughly 66,000 CVEs for 2026, and only a small fraction ever see real-world exploitation. Two public data sources close the gap between severity and exploitation. The FIRST Exploit Prediction Scoring System (EPSS) gives each CVE a daily-updated probability of exploitation in the next 30 days, and the CISA Known Exploited Vulnerabilities (KEV) catalog lists what is being exploited right now. I want to walk a prioritization rule that uses both, run it against real AI-tool CVEs from 2026, and mark where this practice stops.
The three signals and what each one means
Three inputs drive the rank, and each answers a different question.
CVSS answers "how bad is the outcome if this is exploited." It is a severity measure, static per CVE, ranging 0 to 10. It is necessary context and a poor queue-ordering key on its own.
EPSS answers "how likely is exploitation in the next 30 days." It is a probability from 0 to 1, refreshed daily by FIRST from observed exploitation signals. A CVE at EPSS 0.94 is in the top percentile of exploitation likelihood; one at 0.002 almost certainly will not be touched.
KEV answers "is this being exploited today." It is a binary catalog entry from CISA, and an entry carries a federal remediation due date under Binding Operational Directive 22-01. Presence in KEV overrides the probabilistic signals, because KEV is observation rather than prediction.
The prioritization rule
Rank the AI-stack patch queue in this order:
- On CISA KEV: patch now. A KEV entry means active exploitation is confirmed. The EPSS probability is irrelevant once exploitation is observed. Treat the CISA due date as your ceiling, not your target.
- EPSS at or above 0.5 with CVSS 7.0 or higher: patch this cycle. High exploitation likelihood on a high-severity flaw in a component you run.
- EPSS 0.1 to 0.5: schedule. Meaningful probability; slot into the normal maintenance window.
- EPSS below 0.1: defer and monitor. Re-check on the daily EPSS refresh, because a proof-of-concept release can move a score sharply upward within days.
The rule that saves the most time is the inversion: a CVSS 9.8 with EPSS 0.003 and no KEV entry does not lead the queue, and clearing those from the top of the list is where teams recover their week.
Worked example: the AI inference stack, mid-2026
Point the rule at the AI tools you actually run. Take four real 2026 disclosures in that space:
The two KEV entries lead regardless of anything else, because CISA added them on confirmed exploitation and both carried hard federal due dates. The LiteLLM authentication bypass without a KEV listing lands in the patch-this-cycle band on severity plus a non-trivial EPSS. The last row, a high-CVSS infrastructure flaw with an EPSS near zero and no exploitation signal, sits at the bottom and gets watched rather than emergency-patched. That single reordering is the point of the practice. The exploitation windows here are the reason it matters: public tracking put LiteLLM CVE-2026-42208 at roughly 26 hours from advisory to observed exploitation and LMDeploy CVE-2026-33626 near 13 hours, so a queue ordered by severity alone loses the race on the CVEs that are actually being used.
Wiring it into a pipeline
Both feeds are queryable. EPSS publishes a daily CSV and a public API keyed by CVE ID, and CISA publishes KEV as JSON. A nightly job that pulls both, joins them against your software bill of materials for the AI stack, and emits a ranked list is a day of work:
Feed it the CVE and CVSS pairs from your inventory, sort by band, and the queue orders itself against exploitation reality rather than severity theater.
Where patch prioritization stops
Prioritization ranks the work. It does not do the work, and it does nothing during the interval between a disclosure and the patch reaching production. That interval is the exposure, and on the AI stack it is measured in hours while patch cycles run in days. Prioritization also cannot help with a flaw that has no patch yet, and it sits entirely outside the request path where an exploit actually lands. Closing the exposure window is a runtime problem, and that is a control question rather than a queue-ordering question.
DeepInspect
Patching your AI inference stack is your vulnerability-management job, and it sits outside what a network proxy does. DeepInspect does not patch LiteLLM or Langflow, and this guide is about ranking that work with EPSS and KEV so the right patches ship first.
What DeepInspect provides is the compensating control that holds the exploitation window. DeepInspect is a stateless proxy on the AI request path that binds every call to a verified identity and holds no long-lived provider keys, so an unrecognized in-environment identity making model calls is flagged and can be blocked inline, and every decision is written to a per-decision audit record. When an actively exploited CVE in an AI tool has no patch in production yet, identity-bound inline policy is the layer that keeps a disallowed call from executing while the patch is still in the queue, inline and fail-closed. It is a control on the request path, and it complements the patch work rather than replacing it. Book a demo today.
Frequently asked questions
- Is EPSS a replacement for CVSS?
No. They measure different things and are meant to be used together. CVSS scores the severity of the outcome if a vulnerability is exploited, and it is static per CVE. EPSS scores the probability of exploitation in the next 30 days, and it updates daily. A high-CVSS, low-EPSS vulnerability is severe in principle and unlikely to be touched in practice, so it should rank below a moderate-CVSS, high-EPSS flaw in a component you run. Use CVSS for impact context and EPSS plus KEV for queue ordering.
- What does a CISA KEV listing change about my priority?
Everything above it. A KEV entry means CISA has confirmed active exploitation in the wild, so the probabilistic EPSS signal becomes moot and the vulnerability goes to the front of the queue. KEV entries also carry federal remediation due dates under Binding Operational Directive 22-01, which are a useful ceiling even for non-federal teams. Treat any KEV-listed CVE in your AI stack as a patch-now item regardless of its CVSS or EPSS.
- How does this apply specifically to AI tools?
AI inference tooling has seen a run of high-severity CVEs in 2026, including authentication bypasses and remote code execution in gateways and orchestration tools, several with same-day exploitation. The prioritization rule is identical to the rest of your stack, and the difference is inventory: you need your AI components in a software bill of materials so the nightly EPSS and KEV join actually covers LiteLLM, Langflow, inference servers, and framework dependencies. Uninventoried AI tools are the ones that get missed.
- What covers the gap between disclosure and patch?
A runtime control on the request path, because prioritization and patching both operate before or after the exposure window rather than during it. For AI traffic specifically, an identity-aware inline policy layer can block a disallowed or unrecognized call while the patch is still in the queue, which holds the exploitation window that patch cadence alone leaves open. Prioritization decides what to patch first; a compensating control decides what is allowed to execute in the meantime.