Cve Intelligence

Known Chained Vulnerabilities™: pairs of CVEs that a cited source reports were used together in one exploit chain (VulnCheck KEV entry text, Metasploit modules, SigmaHQ rules, press, research or academic sentences, community text judged by a local model). Each row carries both CVEs with their CISA KEV status, the claim kind (observed: the source reports attacks; potential: the source reports they can be chained), the quoted evidence with its source, URL and date, and community discussion counts, which show discussion and are not chain claims. The per-CVE record carries chains.known and chains.candidates (KCV Watch: possible chains for teams to research, pairs whose extracted exploit capabilities connect or whose records tie them together, derived and never confirmed, each with its tier, lane, reasons, basis, product, bridge, grade, a caption and the entry step where one is extracted); search_cves accepts chained=1 and chainability=1. Filters: source (vulncheck_kev, metasploit, sigma, press, research, community), since (YYYY-MM-DD, first seen), claim (observed|potential), limit (1..50).

Full intelligence record for one CVE: per-scorer CVSS, EPSS, CISA KEV/ransomware/SSVC, four remote-detection modalities (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 the Sigma log-detection layer, both kept out of scannable coverage, per-product fixed versions (fixed = first patched build; affected_through = the last vulnerable build, so upgrade past it), news/community coverage, intelligence summary, and bod_26_04: the BOD 26-04 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 (kev_required_action, CISA's requiredAction field); the agency's exposure tag decides the row. other_databases lists the CVE's records in ENISA's EUVD, BDU (FSTEC of Russia), CNVD (CNCERT/CC) and JVN iPedia (JPCERT/CC and IPA) with the address of each. products lists the vendor and product pairs the page lists and the CPE entries NVD's configurations name: with cpes_source nvd_configurations, configurations carries them as NVD writes them (each entry's vulnerable flag, AND and OR operators, negate and the version bounds verbatim, up to 100 matches here, configurations_cap for more), and cpes their names; with nvd_cpe_list, cpes holds the first 25 names in sort order our NVD ingest stores, flagged by cpes_may_be_incomplete. No key required over MCP; an API key on the HTTP request (Authorization: Bearer cvs_live_…) is honored for attribution. Absence semantics: a null field means this dataset holds no such record. The source may still hold one.

CVEs whose EPSS exploitation probability rose the most recently. window is "7d" (default) or "30d". Each rise is measured between same-EPSS-model-version scores, so a model release (which shifts the whole distribution) never appears as a mover. A rise raises the priority of a CVE; observed exploitation is recorded through CISA KEV. Returns cve_id, current score, the delta, KEV status and url, largest rise first.

The Defender Scoreboard report (CC BY 4.0): exploited vs detectable vs patchable, every figure with its method, caveat and denominator, plus the corpus block and any method-change notes. Cite as "CVE Security Defender Scoreboard, cve-security.com/scoreboard".

Field sightings: CVEs a named sensor network recorded in the last 7 or 30 days, most sighting days first. A field sighting is a day on which Shadowserver honeypots (cited by VulnCheck KEV and published as daily lists by CIRCL Vulnerability-Lookup) or VulnCheck canary sensors recorded traffic aimed at the CVE. Each row carries first and last sighting day, days sighted in the last 7 and 30, the sensors, and per-sensor detail including a 30-day presence strip. Presence per day, without volume; a sighting stays apart from the exploitation claims and from CISA KEV. Filters: window (7|30, default 7), kev (0|1), limit (1..50).

The publication change stream: what this site published, stamped with OUR publish time (first_published, kev_added, detection_added, remediation_added, first_sighted, chain_added, and the BOD 26-04 Table 1 input changes ssvc_changed, kev_due_changed, kev_triage_flag_changed, kev_notes_changed, which fire on value changes between snapshots; a timestamp refresh alone fires none). Pass since (YYYY-MM-DD, strictly-after) on the first call, then the returned next_cursor to continue. Over MCP the stream covers the last 30 days, up to 50 events per call: since defaults to 30 days ago, and an earlier since or cursor returns an error. Optional cve scopes the stream to one CVE's change history, with no 30-day cutoff; follow next_cursor past the first 50 events. Events for withdrawn CVE ids are omitted. The keyed GET /api/updates walks the full history.

CVEs affecting one open-source package, by purl (pkg:npm/lodash) or ecosystem + name (Maven names are group:artifact). Returns the CVE list KEV-first with each OSV version range VERBATIM: `events` plus one render-safe projection: `fixed` (the upgrade targets) or `affected_through` (the last VULNERABLE version, so upgrade past it). This tool does not evaluate version membership; compare versions on your side with your ecosystem’s own semantics. Covers CVE-linked, GitHub-reviewed OSS advisories via OSV.dev; absence is not evidence of safety.

Search the catalog. Free text (q) and/or structured filters: vendor (slug), cwe (CWE-nnn), technique (ATT&CK id, such as T1190), year ("2024,2025"), sev ("critical,high"), kev (0|1), kev_from / kev_to (ISO days, half-open CISA listing window; imply kev=1), kev_vendor (the CISA vendorProject string verbatim, such as "Microsoft"), ransomware (0|1), detect (0|1, a detection signal we track), fix (0|1; fix=0 means the fix status was computed and this dataset holds no actionable vendor fix), automatable (0|1, CISA SSVC Automatable; 1=yes, 0=CISA assessed no, unassessed CVEs match neither), sighted (7|30: a named sensor network recorded the CVE in the last 7 or 30 days, a field sighting; presence per day, apart from the exploitation claims), malware (0|1: a published source ties a named malware family, tool, campaign or ransomware group to the CVE), watch (0|1: on KEV Watch at tier 1 or 2, reported exploited by trackers other than CISA and outside CISA KEV), epss_gte (0..1), ti (total|partial: CISA SSVC Technical impact, for CVEs with a CISA assessment held), triage_flag (0|1: CISA's forensic triage flag on the KEV entry), ssvc (0|1; ssvc=0 selects rows with no CISA SSVC assessment held), bod (3df|3d|14d|60d|fsu: the BOD 26-04 Table 1 read at the stated exposure, with exposed 0|1, default 1; a mapping at that exposure, and an agency's timeline still needs its own enumeration date), eco (OSS ecosystem, such as npm or PyPI), pkg (pkg_key, such as npm/lodash; for ranges use query_package), page (1..5), limit (1..50). Filter-only queries return the /browse slice ordered KEV-first then EPSS.

BOD 26-04 Table 1 read for up to 50 CVEs at a stated asset exposure. Per CVE this dataset supplies CISA KEV status and due date, CISA's SSVC Automatable and Technical impact (Vulnrichment) and CISA's forensic triage flag on the KEV entry; you supply exposure for the asset (yes, no, or unknown, which returns both branches). Each item carries the Table 1 row and timeline for the stated exposure, both branches, kev_feed (which branch reproduces CISA's due date and flag pair, if any) and the fix and detection state held, lanes listed separately. A row is a mapping; an agency's timeline for an asset also needs the agency's own enumeration date, so no date is returned beyond CISA's KEV due date. basis says where the values came from: cisa_ssvc, cisa_interim (a CVE outside KEV with no CISA assessment held takes CISA's interim values) or kev_unassessed (a KEV entry with no values held gets no rows).