CVE Triage
A scanner hands you four hundred CVE ids and a severity column that calls most of them critical. This desk ranks the list by what is actually being exploited: the CISA KEV catalog for known exploitation, FIRST EPSS scores for exploitation probability, and CVSS for impact — every input printed next to the priority it produced, so the order is auditable, not a magic number.
No CVE ids found in the input yet.
Working through a patch queue every week? Monitor your sites free with myeventwatch — expiry and downtime alerts, no card required.
How the ranking works
Each id is looked up in three sources and given a priority band from the first rule it matches. P1 is membership of the CISA Known Exploited Vulnerabilities (KEV) catalog: these are not predictions — CISA lists a CVE only with evidence of active exploitation — so a KEV entry outranks everything, and the table shows its remediation due date and whether CISA flags known ransomware use. P2 is an EPSS score of 0.10 or higher: EPSS, maintained by FIRST, models the probability that a CVE will be exploited in the next 30 days, and 0.10 is high — the large majority of scored CVEs sit below 0.01, so the percentile column is shown too, to keep the raw score honest. P3 is a CVSS base score of 7.0 or higher (High or Critical) with no exploitation signal: severe if used, not known to be used. P4 is everything else that has data. Within a band, rows sort by EPSS, then CVSS — and every column header re-sorts the table, because your queue may legitimately differ from the default order. What the band never does is hide its inputs: if you disagree with a row's priority, the numbers it came from are on the same line.
Where the data comes from, and how fresh it is
The KEV catalog and the EPSS scores are cached daily on sysosx's server — both publishers release one bulk file a day, so the desk downloads those files once a day and your lookup reads the local copies. The result header states each feed's own date (the catalog's release date, the EPSS scoring date) and when it was fetched, so you always know which day's data ranked your list. CVSS is the exception: neither KEV nor EPSS carries it, so scores come from the NVD — fetched once, the first time a CVE is looked up, and cached permanently on the server, because a published CVSS score does not change. A very fresh paste can therefore show a few scores as pending: that means the cache has not reached those ids yet, not that they lack scores — re-run the list shortly after and they fill in. Fresh lookups are limited per visitor like the other server-side checks, and repeating the same paste is served from a short cache. Under the hood, the page calls GET /api/check/cve-triage on sysosx's server with the extracted ids.
What this desk cannot tell you
Three honest limits. First, “Not in today's cached data” is an absence from three datasets, not a verdict: it is not known-exploited, it carries no EPSS score, and NVD has no record — it may still be new, disputed, or scored under a different id, and it deserves a manual look rather than a shrug. Second, exploitation data is about the CVE in the world, not about your asset: a P4 on an internet-facing server can outrank a P1 on an air-gapped test box, and only you know which is which — triage the internet-facing batch first, which is also why the desk takes 200 ids at a time rather than pretending one ranking fits a whole estate. Third, KEV listing lags exploitation and EPSS is a model, not an oracle; both are far better evidence than severity alone, and neither replaces reading the vendor advisory for the P1s. The reasoning behind the ranking — and a worked example — is in triage CVEs by exploitation, not just severity.
Related tools: the port scanner for which services a host actually exposes (the asset half of every CVE decision), the website health check for the same host's certificate, expiry and records, and the SSL grader when the finding is a TLS configuration rather than a CVE.
Frequently asked questions
Where does the data come from, and how fresh is it?
Three public sources, each labelled with its date in the result. The CISA Known Exploited Vulnerabilities catalog and the FIRST EPSS daily scores are downloaded to sysosx's server once a day and cached there — your lookup reads the local copy, it does not query CISA or FIRST live. CVSS scores come from the NVD: the first lookup of a CVE fetches it once and caches it permanently, because a published CVSS score does not change. If a score reads "pending", the cache has not reached that CVE yet — re-run the list in a minute and it fills in.
A CVE from my scanner is missing or shows "not in today's cached data". Is it safe?
No conclusion like that is available, and the page will not pretend otherwise. "Not found" means only that the id appears in none of today's cached sources — it is not in the KEV catalog, it has no EPSS score in the current file, and NVD has no CVSS record for it. New CVEs appear daily, EPSS scores only CVEs it has modelled, and a CVE can be real, serious and simply too new for any of the three. Treat missing rows as "triage by hand", not as "ignore".
Why is a CVSS 9.8 ranked below a CVSS 7.5?
Because the ranking is by exploitation, not by impact. The 7.5 is in the KEV catalog: attackers are known to be using it, so it is P1. The 9.8 has a high EPSS score or none — severe if exploited, but no evidence anyone is exploiting it yet. Severity tells you how bad a breach would be; KEV and EPSS tell you how likely an attempt is. Patch order should follow likelihood first and use severity as the tiebreak, which is what the P1–P4 bands encode. The article linked below works through the reasoning in full.
What do the priority bands mean exactly?
P1: the CVE is in the CISA KEV catalog — known exploited, patch now, and note the KEV due date column. P2: not in KEV, but its EPSS score is 0.10 or higher — a modelled 10%+ chance of exploitation in the next 30 days, which is rare air (well under 1% of scored CVEs). P3: neither of those, but a CVSS base score of 7.0 or higher (High or Critical). P4: it has data but meets none of the thresholds — schedule it normally. Every input behind the band is printed in its own column; the band is a sort order, not a score you have to take on faith.
Can I triage more than 200 CVEs?
The desk accepts 200 ids per lookup — paste the list in two batches. That cap keeps one request from monopolising the checker, and in practice a scanner export is more useful split by asset group anyway: triage the internet-facing batch first, because the same CVE is a different emergency on a public server than on an isolated workstation.