# CVE Security

> Per-CVE exploitation, detection and remediation intelligence: CISA KEV
> status, EPSS, four remote-detection modalities (Nuclei, Metasploit check
> modules, Emerging Threats, Snort; the checks that work over the network) plus
> a host-check tier (self-contained Nuclei templates and Metasploit local
> modules that run on the system itself) and a Sigma log-detection layer, both
> tracked separately and kept out of the scannable counts, per-product fixed versions
> with upgrade targets, per-scorer CVSS, and news/community signal across
> ~353K served CVEs.

Absence semantics, site-wide: a null or missing field means this dataset holds
no such record for it. The source may still hold one. Quote figures with that
caveat; every scoreboard number ships with its method and caveat text.

Scores: each CVSS score carries its scorer. The severity band and sort on every
list read one score per CVE, `scores.best` in the record: NVD's v3.1, then NVD's
v4.0, then the best score the assigning CNA or an ADP gave, with `source` and
`scorer` naming who gave it. `scores.nvd_v31` and `nvd_v40` are NVD's own
metrics (source nvd@nist.gov); `scores.by_source[]` lists every scorer's row
under its name.
Quote the scorer with the score.

Denominator policy: every count on this site excludes rejected/withdrawn CVE
identifiers (~17.7K as of 2026-07; their pages return HTTP 410). Raw registry
totals that include those identifiers read higher by exactly that exclusion, so
the difference is policy, not missing coverage. Headline counts on /, /sources,
/detectable and /coverage come from one snapshot, refreshed hourly, stamped "Counts as of"
on each page. Counts and CVE data refresh hourly.

## API

- [OpenAPI specification](https://cve-security.com/openapi.json): every endpoint, auth, response shapes
- [Authentication and registration](https://cve-security.com/auth.md): self-serve key in one POST, with no OAuth or browser step
- [API documentation](https://cve-security.com/api): human-readable docs and signup
- [API catalog](https://cve-security.com/.well-known/api-catalog): RFC 9727 linkset
- MCP server: `POST https://cve-security.com/api/mcp` (stateless streamable-HTTP JSON-RPC for assistants working with a person; all tools keyless: get_cve, search_cves, query_package, get_updates, get_scoreboard, get_epss_movers, get_sightings, get_chains, table1_read; plus resources llms.txt + openapi.json; 100 tool calls per caller per UTC day; a key is honored for attribution and counts calls against the key's daily limit in place of that budget)
- [MCP server card](https://cve-security.com/.well-known/mcp/server-card.json): machine-readable server metadata; connect with `{"type":"http","url":"https://cve-security.com/api/mcp"}`

## Open data (no key needed)

- [Defender Scoreboard report](https://cve-security.com/api/scoreboard/scoreboard.json): exploited vs detectable vs patchable, each figure with method, caveat and denominator. CC BY 4.0, cite as "CVE Security Defender Scoreboard, cve-security.com/scoreboard"
- CVE lists behind each figure: `/api/scoreboard/<metric_key>.csv` (metric keys are listed in the report)
- Atom feeds: [/feeds/updates.xml](https://cve-security.com/feeds/updates.xml) plus `/feeds/updates/{new-cves|kev|detection|remediation|sightings|chains|ssvc|kev-due|kev-triage-flag|kev-notes}.xml` (newest 100; the last four are the BOD 26-04 Table 1 input changes, fired on value changes between snapshots), and [/feeds/epss-movers.xml](https://cve-security.com/feeds/epss-movers.xml) (biggest 7-day EPSS risers)
- Per-entity watchlist feeds (Atom `.xml` or JSON Feed `.json`): `/feeds/vendor/<slug>`, `/feeds/product/<slug>`, `/feeds/package/<eco>/<name>` (e.g. /feeds/package/npm/lodash.xml), `/feeds/attack/<Txxxx>`: the publication stream scoped to one vendor, product, OSS package or ATT&CK technique
- [CISA BOD 26-04](https://cve-security.com/bod-26-04): the directive's Table 1 as this dataset reads it: the KEV entries CISA flags for forensic triage, CISA's due dates in the next seven days, the CVEs outside KEV that Table 1 maps to three days on a publicly exposed asset, and the unassessed set where CISA's interim values apply; Atom feeds [/feeds/kev-triage.xml](https://cve-security.com/feeds/kev-triage.xml) and [/feeds/table1-three-days.xml](https://cve-security.com/feeds/table1-three-days.xml); the working set as [/bod-26-04.csv](https://cve-security.com/bod-26-04.csv) with column names from CISA's BOD 26-04 standardized data schema where a field exists there (keyless, CC BY 4.0)
- SOC-tool exports (keyless, CC BY 4.0): [/detection.csv](https://cve-security.com/detection.csv) (one row per detectable CVE: Nuclei template id, Metasploit module, ET/Snort SIDs, Sigma rule ids, identifiers only), and [/attack/layer.json](https://cve-security.com/attack/layer.json) (MITRE ATT&CK Navigator layer of CVE→technique coverage; `?view=all|kev|direct` or `?vendor=<slug>`)
- Structured search: `/api/search` accepts `vendor, cwe, technique, year, sev, kev, kev_from, kev_to, kev_vendor, ransomware, detect, fix, automatable, ti, triage_flag, ssvc, bod, exposed, sighted, malware, watch, chained, chainability, epss_gte` with or without `q`: filter-only queries return the /browse slice as JSON (`bod=3df|3d|14d|60d|fsu` with `exposed=1|0` is the BOD 26-04 Table 1 read at a stated exposure, a mapping at that exposure)
- MCP (for assistants working with a person): all nine tools keyless, with 100 tool calls per caller per UTC day; a network Cloudflare verifies as an AI assistant or AI search service shares a pool of 5,000 calls a day. The tools include `get_cve`, `table1_read` (the BOD 26-04 Table 1 read for up to 50 CVEs at a stated asset exposure, with the fix and detection state held), `get_updates` (the change stream for the last 30 days, or one CVE's whole history), `get_epss_movers` (biggest EPSS risers, 7d/30d), `get_sightings` (field sightings: CVEs a named sensor network recorded in the last 7 or 30 days, up to 50 rows), `get_chains` (known chained pairs: CVEs a cited source reports were used together in one exploit chain, each row quoting the source, up to 50 rows), and `query_package`: CVEs for one OSS package by purl (pkg:npm/lodash) or ecosystem+name, version ranges returned verbatim (`fixed` = upgrade targets; `affected_through` = the last vulnerable version, so upgrade past it; no server-side version verdicts). Integrations, mirrors and scheduled jobs use the keyed REST API below.
- Markdown page variants (keyless): any CVE page at `/cve/cve-YYYY-NNNN.md`: the same record `/api/cve` returns, serialized as Markdown; the scoreboard at `/scoreboard.md`

## Keyed (free account, one POST; integration surfaces)

- `GET /api/updates`: the cursor-based publication change stream over REST, `?since=YYYY-MM-DD`, then walk `next_cursor` through the full history. The MCP `get_updates` tool serves the last 30 days to assistants, and the Atom feeds carry the newest-100 window
- `GET /api/package/{purl-type}/{name}` (or `?purl=pkg:npm/lodash`): CVEs affecting one open-source package, KEV-first, OSV ranges verbatim. The MCP `query_package` tool answers the same lookup for assistants
- `POST /api/sbom`: check a whole SBOM (CycloneDX JSON 1.2 through 1.7, SPDX JSON or `{"purls": […]}`) in one call, joined on this server and not retained; verdictless (ranges verbatim, you evaluate versions). Purls go to the package mapping. A `cpe` on a device, firmware or operating-system component (a CPE 2.3 formatted string or a CPE 2.2 URI such as Nmap prints; `?cpe=all` for every component) goes to NVD's configurations, and the answer adds one result per walked component (`matched`, `runs_on_only`, `no_match_in_our_data`, `counts_only`, `over_cap` or `unresolved`) and `cpe_matched`, each CVE with its attachments to the BOM's components, with NVD's configurations whole in `cpe_configurations`: a range attaches to a component when the configuration's other parts sit in the same device. `?format=cyclonedx`, or an Accept header that ranks `application/vnd.cyclonedx+json` first, asks for a CycloneDX 1.6 document, 1.7 with `?spec_version=1.7`: every component echoed with its result, `affects` only where NVD's configuration or OSV names the component as affected, each version entry with `status: affected`, no `analysis` block. In the Accept header, a tie with an explicit `application/json` entry answers JSON, and a tie with a wildcard answers CycloneDX. That answer is built and stays off until the `cve-security` property namespace is registered in the CycloneDX property taxonomy: until then `?format=cyclonedx` and an Accept header that excludes JSON return 501, and a header that also accepts JSON (`application/json`, or a wildcard with no `application/json;q=0`) gets the JSON answer; [/cyclonedx-properties](https://cve-security.com/cyclonedx-properties) lists its properties

## Bulk export (key required, CC BY 4.0)

- [KEV Watch](https://cve-security.com/kev-watch): CVEs that VulnCheck, Microsoft, Project Zero, ENISA, CIRCL or FortiGuard report as exploited while they remain outside CISA KEV, each report cited, with the measured 90-day CISA-listing rate of each evidence pattern. A row also carries the reports of BDU (the vulnerability database of the Federal Service for Technical and Export Control of Russia, read through CIRCL Vulnerability-Lookup) and of Previdian (previdian.com), credited to each; the tiers read the six trackers named first. Atom: `/feeds/kev-watch.xml`; keyed JSON: `/api/kev-watch.json?tier=1|2|3|4` (paged with `limit` and `page`)
- [Field sightings](https://cve-security.com/sightings): CVEs a named sensor network recorded in the last 30 days, most sighting days first. A field sighting is a day on which Shadowserver honeypots (cited by VulnCheck KEV, published as daily lists by CIRCL Vulnerability-Lookup) or VulnCheck canary sensors recorded traffic aimed at the CVE; presence per day, apart from the exploitation claims and from CISA KEV. Atom: `/feeds/sightings.xml` (first sighted this week); keyed JSON: `/api/sightings.json?window=7|30&kev=0|1`; the per-CVE record carries `exploitation.sightings`; `/api/search?sighted=7` filters the catalog
- [Known Chained Vulnerabilities™](https://cve-security.com/chains): pairs of CVEs that a cited source reports were used together in one exploit chain (VulnCheck KEV entry text, Metasploit modules, SigmaHQ rules, press or research sentences, community text judged by a local model), each row quoting the source with its URL and saying whether the source reports attacks (observed) or a possible chain (potential); plus KCV Watch, chain candidates: pairs whose extracted exploit capabilities connect (what one CVE yields satisfies what the other requires) or whose records tie them together (exploitation reports on both within 90 days, an authentication bypass disclosed with a partner, two products that sources tie together), derived from exploit-capability analysis by the CVE Security intelligence team and published as possible chains for teams to research, each with its tier (A, B or C: pairs with these signals are estimated as possible chains at a rate of at least one in 25, one in 100 or one in 1,000; a pair reaches tier A only with a documented capability handoff; the site lists A and B, and tier C is in the record, the API and the download /api/export/kcv-watch.jsonl.gz), lane, reasons, basis (how many of the two CVEs carry an exploitation report or field sighting), the product the pair shares, bridge, capability-match grade, and the entry step and its reach where one is extracted (a local entry means a prior step could supply the access). Atom: `/feeds/chains.xml`; keyed JSON: `/api/chains.json?source=&since=&claim=` for the known pairs and `/api/kcv-watch.json?tier=A|B&limit=2000&page=N` for the candidate list (follow `has_more`; tiers A and B together hold several thousand rows) and `/api/kcv-watch.json?set=breaking` for Breaking watch (connected same-product pairs with an exploitation report or field sighting, any tier, each with `since` and `until`, the first and last day of its stay); the per-CVE record carries `chains.known` and `chains.candidates`; `/api/search?chained=1` and `chainability=1` filter the catalog. A candidate is not a confirmed chain. Academic papers whose own sentence names a chain enter the catalog as an academic evidence lane after our judge reads them.
- Records in other vulnerability databases: each CVE record and page carries `other_databases`, the ids of the CVE's records in ENISA's EUVD, BDU (Russia's Federal Service for Technical and Export Control), CNVD (China National Vulnerability Database, run by CNCERT/CC) and JVN iPedia (Japan's JPCERT/CC and IPA), three a database at most, each with the address of the record and the reason it is tied (`basis`: mapping, cited, single or advisory). The BDU, CNVD and JVN iPedia ids were read through CIRCL Vulnerability-Lookup. `/search?q=CNVD-2026-37980` opens the CVE a record id is tied to
- Products and CPE names: each CVE record carries `products`. `items` holds the vendor and product pairs the page lists, up to 40, each with links to the vendor and product pages; `items_source` says whether they come from NVD's CPE names (`nvd`) or, until this dataset holds those, from the products the assigning CNA lists in its CVE record (`cna`). `cpes` holds CPE 2.3 names, verbatim, and `cpes_source` says where they come from. With `nvd_configurations`, `configurations` carries NVD's configurations for the CVE whole, in NVD's order, up to 500 matches, and `cpes` lists their distinct names. Each configuration and node keeps NVD's operator (AND or OR) and negate flag, and each match keeps its CPE name, NVD's vulnerable flag and NVD's version bounds verbatim (`version_start_including`, `version_start_excluding`, `version_end_including` and `version_end_excluding`). A match with `vulnerable: false` is a platform or hardware the vulnerable product runs on, and an AND configuration holds when all of its nodes match, so a vulnerable firmware and the hardware it runs on read as one combination. An end bound marks where NVD's range stops; the fixed versions this dataset holds are in `remediation`. `configurations_match_count` counts every match NVD lists, and `configurations_may_be_incomplete` marks a set the record cut. With `nvd_cpe_list`, `cpes` holds the first 25 names in sort order our NVD ingest keeps and `configurations` is null. That sort puts application names ahead of hardware and hardware ahead of operating system and firmware names, so a list cut at 25 (`cpes_may_be_incomplete`) can leave out every operating system and firmware name; `items_may_be_incomplete` follows the stored list for NVD pairs. For the CNA's affected and fixed builds, read `remediation.affected_versions`. With `nvd_configurations`, the CVE page and its Markdown twin list the first 25 entries, grouped by configuration, with each entry's role and bounds; with `nvd_cpe_list`, they list the first 25 names in sort order. `configurations` carries up to 500 matches over REST and 100 over MCP `get_cve` by default (`configurations_cap` asks for up to 500)
- Academic papers: each CVE record and page carries `papers`, the peer-reviewed works and preprints that name the CVE (OpenAlex metadata, CC0; papers found through the Semantic Scholar S2ORC corpus credited to Semantic Scholar), titles and links only
- Titles: each CVE record and page carries `title`, set in one house format (vendor, product, component and weakness, in the order CISA uses), and `title_source`, which names where it came from: the name CISA gives the KEV entry, the assigning CNA's title, a vendor advisory, the GitHub Advisory Database (CC BY 4.0), our rules or a language-model draft checked against the CVE record. `exploitation.kev_name` keeps the KEV name as CISA writes it
- `GET /api/panels/index.json` and `/api/panels/<slug>.json` (key required): the dashboard's precomputed panels, KEV listings per month/year, vendor × month matrix, age at listing, catalog overlap (CISA / VulnCheck / EUVD), press attention, coverage by cohort, each with its method, caveat and build stamp. Dates are CISA listing dates, not exploitation dates
- `GET /api/export/cves.jsonl.gz`: the full served catalog (~30 MB gz, one JSON object per CVE), rebuilt nightly; counts as one request
- `GET /api/export/packages.jsonl.gz`: the OSS package↔CVE mapping (~1.6 MB gz, one object per cve/ecosystem/package) with OSV version ranges verbatim + KEV/EPSS per row
- `GET /api/export/manifest.json`: {as_of, count, sha256, fields} for both files (packages under its `packages` key); poll this and compare sha256 before re-downloading

## Key pages

- [Detectable CVEs](https://cve-security.com/detectable): the scan-me-now surface
- [Coverage](https://cve-security.com/coverage): exploited × detectable joins
- Malware claims: the per-CVE record's `malware[]` carries malware families, tools, campaigns and ransomware groups that published sources tie to the CVE (MITRE ATT&CK relationship text; Ransomware Vulnerability Matrix rows after a review against their cited page), each with the quoted sentence and its URL; `/api/search?malware=1` filters CVEs with such a row
- [ATT&CK coverage](https://cve-security.com/attack): the MITRE ATT&CK matrix heat-mapped by CVE coverage (toggle KEV/observed); per-technique CVE lists at `/attack/<Txxxx>`. Sources graded observed (MITRE CTID) > detection (Sigma tags) > weakness (CWE→CAPEC→ATT&CK). `/api/search?technique=T1190` filters CVEs by technique; the per-CVE record's `attack.techniques[]` carries the same, with `source` confidence
- [CNA scorecards](https://cve-security.com/cna): per-CNA record-quality, share of assigned CVEs carrying a CNA score, a CWE and machine-readable versions, plus NVD severity-band agreement. Ranked on shares, gated to ≥50 CVEs; every figure drills into `/browse?assigner=<slug>&…`. Vendor pages carry the same scorecard scoped to one vendor
- [Scoreboard](https://cve-security.com/scoreboard): the recurring measurement, human-readable
- [Sources](https://cve-security.com/sources): every upstream feed behind the data
- [Glossary](https://cve-security.com/glossary): KEV, EPSS, SSVC, CVSS and friends, defined
- [About](https://cve-security.com/about): who operates the site and how to reuse the data
- [Contact](https://cve-security.com/contact): the form that reaches the team, for questions, data corrections, security reports and licensing requests
- [Methodology](https://cve-security.com/methodology): pipeline, absence semantics, detection/remediation counting rules, and how the machine-generated summaries are produced

## Usage notes

- CVE pages: `https://cve-security.com/cve/cve-YYYY-NNNN` (lowercase). JSON:
  `GET /api/cve/CVE-YYYY-NNNN` with `Authorization: Bearer <key>` (free, 1,000/day).
- CISA SSVC "poc" means exploit CODE is public, it is NOT evidence of
  exploitation in the wild. KEV listing is the exploitation ground truth here.
- `bod_26_04` on every CVE record: the BOD 26-04 (CISA, June 10, 2026) Table 1 read
  on both exposure branches, CISA's row numbers and timelines from KEV status and
  CISA's SSVC Automatable and Technical impact, with CISA's KEV due date, forensic
  triage flag and the KEV entry's action text. The agency's exposure tag decides the
  row; the read is a mapping and carries no date beyond CISA's KEV due date. `basis`
  says where the values came from (cisa_ssvc, cisa_interim for a CVE outside KEV
  with no CISA assessment held, kev_unassessed for a KEV entry with none, which
  gets no rows).
- `remediation.affected_versions[].fixed` is the first patched build;
  `affected_through` is the last vulnerable build, so upgrade past it.