CVE Intelligence — NVD joined with CISA KEV and EPSS

$0.49 per 1,000 records. Every vulnerability from the NIST National Vulnerability Database, joined with two authoritative sources that answer the only question that matters on a Monday morning: is this being exploited right now, and what are the odds someone tries it this month?

389,995 CVEs	the whole NIST NVD catalog, read live
1,705 actively exploited	the CISA KEV catalog of Known Exploited Vulnerabilities
371,625 exploit probabilities	EPSS scores from FIRST.org, joined in
One risk score, one priority	0–100 and a plain word, computed from all three
42 flat fields	CVSS is four levels deep in the raw API; here it is a column

The problem this solves

A CVSS score alone cannot tell you what to patch first. There are 30,620 vulnerabilities rated CRITICAL. You cannot fix thirty thousand things this week, and most of them will never be attacked.

Two public datasets already answer that, and almost nobody joins them to the CVE feed:

• CISA KEV lists what is being exploited in the wild today — 1,705 entries, each with the vendor, the required action, a deadline that is legally binding for US federal agencies, and a flag that isolates the ransomware vulnerabilities.
• EPSS gives the probability that an exploit will be attempted in the next 30 days, updated daily.

This Actor fetches the CVE, looks it up in both, and hands you one row.

How the risk score is computed

No black box. The formula is four lines and it is printed here so you can disagree with it:

score  = CVSS base score / 10 x 60      severity of the flaw itself   (0-60)
       + 25   if listed in CISA KEV     being exploited is a fact, not a forecast
       + 5    if used by ransomware crews
       + EPSS x 10                      probability of an attempt in 30 days (0-10)
capped at 100

Priority, in one word

Priority	Meaning
act now	listed in CISA KEV — exploitation is confirmed, not predicted
urgent	risk 80+
high	risk 60–79
medium	risk 40–59
low	below 40

act now ignores the number on purpose. A vulnerability that is being used against real systems outranks a theoretical 9.8. Vulnerability triage, in one column.

Patch prioritization: what the priority column is for

The priority column exists for exactly this — vulnerability prioritization with no model to train and no score to explain away. Turn on Only where a patch is referenced and you get the queue that is actionable today: flaws with a vendor advisory or security update in the references, sorted by risk. Combine it with Only ransomware-linked and you get just the ransomware vulnerabilities with a fix already published — usually a few dozen rows.

Who this is for

Security and platform teams. This is the data layer under vulnerability management: run it daily with Only records not seen before and get just what changed, with the ransomware flag and CISA's deadline already attached. Scheduled CVE monitoring bills you only for what moved.

Managed service providers. Filter by vendor or product to watch only the stack your clients actually run, and bill for the rows you keep rather than the whole database — vulnerability prioritization per client, not per vendor.

Threat intelligence and research. Every field is flat, so the CVE dataset opens in a spreadsheet and loads into pandas without a flattening step.

AI and agent pipelines. Compact output returns 13 core fields with no advisory text — the shape a model consumes — and the risk score gives the agent something to rank on.

Quick start

Press Start for a 300-record sample of the newest entries — the quickest look at what the security feed returns.

{
  "kevOnly": true,
  "minRiskScore": 70,
  "vendors": ["microsoft", "cisco"],
  "maxItems": 0
}

That asks for: exploited in the wild, risk 70 or higher, from two vendors.

Fields

What kind of data this is

This is security vulnerability data assembled from the authoritative sources rather than scraped from a vendor page: NVD for the record itself, CISA KEV for what is being exploited, EPSS for the odds. Vulnerability scanner data tells you what you are running; this tells you which of it matters first.

Weakness types arrive as the CWE identifiers themselves, so a query can ask for SQL injection or out-of-bounds writes instead of guessing at a keyword.

CVSS score data arrives already flat: base score, severity, version, and the vector string unpacked into attack vector and attack complexity, rather than four levels deep in the raw API. Vendor product data is parsed out of the CPE match strings, so a filter can name the products you actually run. Joined with KEV and EPSS, what you end up with is threat intelligence data rather than a catalogue — what is being exploited today, and what is likely to be next.

Each row is security patch data as much as a vulnerability record: the has_patch flag, the reference URLs and the CISA due date sit beside the vulnerability risk score, so one download answers both what to patch and in what order.

Where the file usually ends up

Flat rows drop into whatever already holds your IT security data — a SIEM, a ticket queue, a spreadsheet — and the dataset behind a run is a security data API you read by URL. Risk scoring data you disagree with can be recomputed: CVSS, EPSS and CISA KEV data stay in their own columns, and as security compliance data the row carries the CISA due date.

A schedule with Only records not seen before turns the same file into security alerts data: each morning's rows are the ones that changed, and for a small team that is the whole of the security monitoring data worth keeping. Patch management data comes off the same row — the has_patch flag and the vendor advisory URL beside CISA's deadline — so the ticket queue receives security operations data instead of a link to a website.

All 42

42 per record — identity, CVSS data, KEV status, EPSS odds and the computed score. The ones that do the work:

Field	What it is
cve_id, description, published_at, age_days	the identity of the flaw
cvss_score, cvss_severity, cvss_version, cvss_vector	CVE severity as NVD publishes it — v3.1 if present, otherwise v3.0
attack_vector, attack_complexity, privileges_required, user_interaction, scope_changed	how it is actually exploited, pulled out of the vector string
kev_listed, kev_date_added, kev_due_date, kev_ransomware, kev_action	everything CISA publishes about active exploitation
epss_score, epss_percentile	probability of an exploitation attempt within 30 days
risk_score, priority	the combined answer
vendors, products, cpe_count	parsed out of the CPE match strings
cwe_ids, cwe_names	weakness classification
has_patch, has_exploit, reference_urls	detected from the reference list and its tags
change_type	in incremental runs: NEW, UPDATED or UNCHANGED

Empty means the source did not publish it. A CVE with no CVSS score contributes zero to the base of the risk score rather than a guessed value.

One real record

CVE-2021-44228 as the Actor returned it on 12 September 2026, showing the columns that carry the decision:

Field	Value
cve_id	CVE-2021-44228
cvss_score · cvss_severity	10 · CRITICAL
attack_vector · attack_complexity	NETWORK · LOW
kev_listed · kev_date_added · kev_due_date	true · 2021-12-10 · 2021-12-24
kev_ransomware	true
epss_score · epss_percentile	0.99999 · 1
risk_score · priority	100 · act now
has_patch · has_exploit	true · true
cwe_ids	CWE-20, CWE-400, CWE-502, CWE-917
vendors · products · cpe_count	12 vendors · 166 products · 396

What "has patch" and "has exploit" actually mean

They are derived from the reference list, not asserted by NVD. A reference tagged as a vendor advisory, a release note or a security update sets has_patch. A link to Exploit-DB, Metasploit or a proof-of-concept page sets has_exploit. That is a useful signal, not a guarantee, and this README would rather say so than let you assume otherwise.

Why vendors and products are lists

One CVE can affect dozens of configurations. The raw API buries them in configurations[].nodes[].cpeMatch[].criteria as strings like cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*. This Actor parses every one, deduplicates, and gives you vendors: ["apache"], products: ["log4j"] and cpe_count so you can tell a single-product flaw from one that touches forty.

The three sources by their real names

Nothing here is a screen scrape. All three are public JSON APIs, and this is exactly what an NVD scraper has to speak to get a complete record:

Source	Endpoint	What this Actor asks it
NIST NVD API 2.0	services.nvd.nist.gov/rest/json/cves/2.0	keywordSearch, cveId, cvssV3Severity, hasKev, pubStartDate/pubEndDate, lastModStartDate/lastModEndDate, paged with startIndex and resultsPerPage
CISA KEV catalog	cisa.gov/.../known_exploited_vulnerabilities.json	the whole catalog, once per run, keyed by CVE identifier
EPSS, the Exploit Prediction Scoring System	api.first.org/data/v1/epss	probabilities in batches of 100 identifiers

The NVD date parameters only work in pairs and only span 120 days at a time. You give a number of days; both ends are computed for you.

The CISA catalogue exists because of Binding Operational Directive 22-01 — BOD 22-01 for short — which is why every KEV row carries a remediation deadline and a required action rather than just a flag. The field CISA calls knownRansomwareCampaignUse — ransomware campaign use — becomes kev_ransomware here.

Weakness types: the CWE identifiers you can filter on

cwe_ids and cwe_names come from the NVD weakness block, which uses the MITRE Common Weakness Enumeration. The Weakness types (CWE) input takes the identifiers directly and keeps a record if any of its weaknesses matches. This one is applied after collection, not at the source, so pair it with a keyword or a date window unless you mean to walk the whole database. The counts below were measured against the live NVD API, one query per identifier:

CWE	Weakness	Records in NVD
CWE-79	cross-site scripting	24,543
CWE-787	out-of-bounds write	12,172
CWE-89	SQL injection	11,606
CWE-20	improper input validation	8,908
CWE-125	out-of-bounds read	6,323
CWE-22	path traversal	5,940
CWE-416	use after free	5,313
CWE-352	cross-site request forgery	4,642
CWE-78	OS command injection	3,570
CWE-502	deserialization of untrusted data	1,179

The three identifiers people search for most are CWE-79 for cross-site scripting, CWE-89 for SQL injection and CWE-787 for an out-of-bounds write; the first two are the largest classes in the database and the third is the one that most often turns into remote code execution.

The Common Platform Enumeration side works the same way: a CPE URI such as cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:* is split into the vendor and the product you filter on, and cpe_count tells you how many of them a record carries.

Running it as a CVE monitor

Scheduled CVE monitoring is the cheapest way to run this Actor: you pay for what moved since yesterday, not for the database.

Getting only what changed

Turn on Only records not seen before. Delivered CVEs are remembered in a named key-value store that survives between runs, and every row carries change_type:

• NEW — not seen in any previous run.
• UPDATED — seen before, but the CVSS score, the exploitation status, the EPSS probability or the start of the description changed.
• UNCHANGED — identical; not returned at all unless you ask with Also return unchanged records.

The fingerprint deliberately covers only what changes a decision. NVD rewrites advisory wording constantly; if that counted as an update, your bill would churn for nothing.

A daily vulnerability feed

Set Changed within to 1 and schedule the Actor daily. NVD is asked for records touched in the last 24 hours, which on a typical day is around 1,400 entries rather than 390,000, and the incremental memory removes the ones you already have — a daily security feed for the price of a few hundred rows.

Where the output goes

The CVE dataset is a plain Apify dataset: JSON, CSV and Excel from the run page, or the API at https://api.apify.com/v2/datasets/<id>/items. Apify's integrations push it to Slack, Google Sheets, Zapier, Make or your own webhook — see Apify integrations. A Slack message on every act now record is about five minutes of setup.

Honest limits

There is no pagination wall here, and that is fine

Unlike most sources, NVD lets you page to the end: startIndex works all the way to 389,000. So this Actor claims no cap-beating trick. What it does claim is the join, the flattening and the scoring — and those are checked by the test suite on live data.

The rate limit is the real constraint

Without an API key NVD allows roughly five requests per thirty seconds. This Actor paces itself accordingly and backs off when the server asks. A scraper that ignores this gets HTTP 403 partway through and returns a silently short result. Pulling the entire database takes about twenty minutes; a filtered query takes seconds.

What this Actor does not do

It does not resolve CPE strings into a software inventory, it does not tell you whether you are affected, and it does not invent a CVSS score when the source has none. Those are jobs for an asset inventory, not a data feed.

Questions people ask

How is this different from the other CVE Actors?

They wrap NVD. Measured on the Apify Store: 242 Actors match "cve vulnerabilities", and none of their descriptions mention CISA KEV or EPSS. The CVE record itself is identical wherever you get it — the value is in knowing which of those 389,995 entries is being used against real systems today.

Can I get only the vulnerabilities that matter to my stack?

Yes. Vendors and Products match against the parsed CPE data, so ["microsoft", "fortinet"] narrows the feed to those. Combine with Only actively exploited and you have a short, actionable list instead of a database dump.

What does a first run cost?

The form starts at 300 records, which is under fifteen cents. With no filters and no limit the Actor treats the run as a trial and keeps it to that same size, so an accidental click cannot pull the whole database.

How current is the data?

NVD is queried live at run time. The CISA catalogue is downloaded once per run. EPSS scores carry their own epss_date, which is the day FIRST.org computed them — usually the current day.

Why do some CVEs have no EPSS score?

EPSS covers 371,625 of the 389,995 CVEs. Very new entries and some reserved or rejected ones are not scored yet. Those rows come back with epss_score empty rather than zero, because "not scored" and "zero probability" are different things.

Can I turn the enrichment off?

Yes, with Join CISA KEV and EPSS unchecked. The run is faster and cheaper because it skips the catalogue download and the EPSS batches, but risk_score then rests on CVSS alone and priority loses most of its meaning.

Does it need an API key or a proxy?

Neither. All three sources are public and free. The only cost of going without an NVD key is the pace, which this Actor already respects.

Why those weights and not others?

The weights are chosen so the scale discriminates. Give KEV forty points and every exploited flaw above CVSS 6 pins at 100, leaving nothing to sort by. At these weights Log4Shell (CVSS 10, exploited, ransomware, EPSS 0.99999) scores exactly 100, while a 2004 Microsoft flaw that is exploited but has EPSS 0.05 scores 72.3 — still "act now", but visibly below.

Does the priority ever disagree with the severity?

Often, and that is the point. A CVSS 9.8 that nobody has ever exploited, with an EPSS of 0.002, scores 58.8 and lands in medium. A CVSS 7.5 that CISA lists as actively exploited scores 70 and reads act now. Sorting by severity alone puts the wrong one first.

What happens when NVD is slow or refuses?

The Actor keeps one shared pace per host and backs off when the server signals it. If a request still fails, the failure is recorded in the run report by name rather than quietly shortening your results — a half-delivered dataset that looks complete is worse than an honest error.

Can I pull the whole database in one run?

Yes: leave every filter empty and set Max records to 0. Expect roughly twenty minutes and 195 requests, because the pace is set by NVD's rate limit and not by anything in this Actor. Most people do not need it — a filtered query answers the same question in seconds.

Is the CISA deadline relevant outside the US government?

The kev_due_date is binding only for US federal civilian agencies, but it is a useful public signal regardless: it is the date a government body with access to threat reporting decided the flaw must be gone. Many private teams use it as a default service-level target.

Is this risk-based vulnerability management, or just a CVE dump?

It is the data layer under it. Risk-based vulnerability management means ranking by what is actually being exploited instead of by CVSS alone, and that ranking needs three inputs: severity, real-world exploitation, and the odds of an attempt. This Actor does the vulnerability enrichment — the join of NVD with CISA KEV and EPSS — and the vulnerability prioritization on top of it, as one risk_score and one priority. What it does not do is know your asset inventory, so it cannot tell you which of those flaws you actually run.

How do I check exploit availability for a CVE?

Two different signals, and they mean different things. has_exploit is detected from the reference list: a link to Exploit-DB, Metasploit or a proof-of-concept page. kev_listed is CISA stating that exploitation has been observed. epss_score is neither — it is a forecast. A record can have a public exploit and a low EPSS score, which usually means nobody is bothering.

What does a single lookup look like?

Put CVE-2021-44228 in One specific CVE and you get Log4Shell in one row: CVSS 10.0, kev_listed true, kev_ransomware true, EPSS near 1, risk score 100, priority act now. That record is the worked example the scoring formula above is calibrated against.

A run succeeded but the dataset is empty — is that a failure?

Not necessarily, and the Actor always says which case it is. The run report carries empty_reason and the log carries a warning naming it: nothing-changed (the incremental mode working as asked — everything had already been delivered by an earlier run, so nothing was written and nothing was charged), filtered-out (your filters removed everything that was collected), source-returned-nothing (the search matched nothing at all), or charge-limit-reached (the run's spending limit was already used up). A silent empty dataset is treated as a defect, not as a normal outcome.

Reproducing the numbers

python3 tests/run_all.py --live

The live suite asserts the page-size limit against the real API, checks that the CISA catalogue loads with its ransomware field, verifies that EPSS batches join correctly past the hundred-record limit, and proves that all three sources land in one row. Every figure in this README comes from that run.