# CVE Records $0.49/1K: Security Data, Vulnerability Database (`snow_leo_data/cve-nvd-kev-vulnerability-scraper`) Actor

$0.49/1K | 389,995 CVEs joined with CISA KEV and EPSS — the only feed here that tells you what is exploited RIGHT NOW, what ransomware crews use and the odds of an attack. NVD data, CVE data, KEV catalog, EPSS scores, threat intelligence data, security risk data, vulnerability API.

- **URL**: https://apify.com/snow\_leo\_data/cve-nvd-kev-vulnerability-scraper.md
- **Developed by:** [Snow Leo Data](https://apify.com/snow_leo_data) (community)
- **Categories:** Developer tools, Automation, Other
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.49 / 1,000 vulnerabilities

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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.

```json
{
  "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](https://docs.apify.com/platform/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.

# Actor input Schema

## `keyword` (type: `string`):

Free-text search across NVD — `log4j`, `apache`, `remote code execution`. Leave empty for everything.

## `severity` (type: `string`):

CVSS v3 severity band, applied at the source.

## `kevOnly` (type: `boolean`):

1,705 of the 389,995 CVEs are known to be exploited in the wild. This keeps only those — the ones that are not a forecast but a fact.

## `modifiedWithinDays` (type: `integer`):

Ask NVD for records touched in the last N days. The source accepts windows up to 120 days; both ends are computed for you. Ideal for a daily monitor.

## `publishedWithinDays` (type: `integer`):

Only newly published CVEs. Ignored when "Changed within" is set.

## `cveId` (type: `string`):

e.g. `CVE-2021-44228`. Overrides the other search fields.

## `ransomwareOnly` (type: `boolean`):

CISA marks which exploited vulnerabilities are used in ransomware campaigns. This keeps only those.

## `minCvss` (type: `integer`):

0–10. Records with no CVSS score at all are dropped when this is set.

## `minEpss` (type: `string`):

0–1, e.g. `0.5` for a coin-flip chance of an exploitation attempt within 30 days.

## `minRiskScore` (type: `integer`):

0–100, the combined score described in the README.

## `priorities` (type: `array`):

The plain-English bucket this Actor computes.

## `vendors` (type: `array`):

Matched against vendors parsed out of the CPE strings, e.g. `microsoft`, `cisco`.

## `products` (type: `array`):

Matched against products parsed out of CPE, e.g. `windows_server`, `log4j`.

## `cwe` (type: `array`):

e.g. `CWE-79`, `CWE-89`.

## `keywords` (type: `array`):

Extra text match on the description, vendors and products, after the source query.

## `excludeKeywords` (type: `array`):

Drops a record if any of these appears in its description.

## `withPatchOnly` (type: `boolean`):

Detected from the reference URLs and tags — vendor advisories, release notes, security updates.

## `withExploitOnly` (type: `boolean`):

Detected from references to Exploit-DB, Metasploit, proof-of-concept pages.

## `maxAgeDays` (type: `integer`):

0 = any age. Applied after collection, unlike "Published within".

## `enrich` (type: `boolean`):

On: every record carries exploitation status, ransomware use and exploit probability, and the risk score is meaningful. Off: NVD only, and the run is faster.

## `includeDescription` (type: `boolean`):

The advisory text is the largest field. Turn it off for smaller rows.

## `compactOutput` (type: `boolean`):

13 core fields only — for AI agents and dashboards.

## `excludeEmptyFields` (type: `boolean`):

Leave out what the sources did not provide instead of returning it empty.

## `onlyNew` (type: `boolean`):

For schedules. Delivered CVEs are remembered in a named store that survives runs, so a daily run returns — and charges for — only what is new or changed.

## `emitUnchanged` (type: `boolean`):

Off by default: an unchanged record is something you already paid for.

## `maxItems` (type: `integer`):

0 = no limit. The form starts at 300 so a first run is quick and cheap.

## Actor input object example

```json
{
  "severity": "",
  "kevOnly": false,
  "modifiedWithinDays": 0,
  "publishedWithinDays": 0,
  "cveId": "",
  "ransomwareOnly": false,
  "minCvss": 0,
  "minEpss": "",
  "minRiskScore": 0,
  "priorities": [],
  "vendors": [],
  "products": [],
  "cwe": [],
  "keywords": [],
  "excludeKeywords": [],
  "withPatchOnly": false,
  "withExploitOnly": false,
  "maxAgeDays": 0,
  "enrich": true,
  "includeDescription": true,
  "compactOutput": false,
  "excludeEmptyFields": false,
  "onlyNew": false,
  "emitUnchanged": false,
  "maxItems": 300
}
```

# Actor output Schema

## `vulnerabilities` (type: `string`):

Every record collected in this run. Open the Act now view for what is being exploited today.

## `report` (type: `string`):

KEV matches, filter counts and request totals.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "keyword": "",
    "maxItems": 300
};

// Run the Actor and wait for it to finish
const run = await client.actor("snow_leo_data/cve-nvd-kev-vulnerability-scraper").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "keyword": "",
    "maxItems": 300,
}

# Run the Actor and wait for it to finish
run = client.actor("snow_leo_data/cve-nvd-kev-vulnerability-scraper").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "keyword": "",
  "maxItems": 300
}' |
apify call snow_leo_data/cve-nvd-kev-vulnerability-scraper --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,snow_leo_data/cve-nvd-kev-vulnerability-scraper"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/0DnSWbB2O59wtATgx/builds/cuJNwbta6Kb0bdJo8/openapi.json