ZEN SecDB

cloud.nttzen.secdb/zen-secdbVersion 1.0.0

ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.

Status

Responds121 msNov 14, 2026, 13:42 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 13:42 UTC
Latency: 121 ms
Remotes responding: 1 of 1
Sign-in: No sign-in
Hosting: EU hosting detected (detected, not a legal statement)
Registry data as of: Nov 14, 2026, 22:14 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://secdb.nttzen.cloud/mcpResponds121 msNov 14, 2026, 13:42 UTC

No sign-in

Claude Code

claude mcp add --transport http zen-secdb https://secdb.nttzen.cloud/mcp

Claude Desktop and claude.ai

1
2
3

Settings > Connectors > Add custom connector
Name: zen-secdb
Remote MCP server URL: https://secdb.nttzen.cloud/mcp

Cursor

{
  "mcpServers": {
    "zen-secdb": {
      "url": "https://secdb.nttzen.cloud/mcp"
    }
  }
}

VS Code

code --add-mcp '{"name":"zen-secdb","type":"http","url":"https://secdb.nttzen.cloud/mcp"}'

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

23 tools

Tools of ZEN SecDB
	Description		Read-only	Idempotent	Open world
`advisory_info`Get detailed information about a specific security advisory. ## What this tool does Retrieves a security advisory (for example RHSA, DSA, USN, GHSA) from SecDB, including title, publication date, severity, summary, description, linked CVEs, CVSS metrics, weaknesses, and the affected and fixed packages and products. ## When to use this tool Use this tool when the user asks: - "Give me details about RHSA-2026:1234." - "Which CVEs are fixed by this advisory?" - "Which package versions are affected, and which version fixes them?" For a CVE, use `vulnerability_info`. If the exact advisory ID is not known, use `vulnerability_search` with `type` set to `advisory`. ## Inputs - advisory_id: exact advisory identifier (e.g. `RHSA-2026:1234`, `GHSA-xxxx-xxxx-xxxx`). ## Outputs - advisory_id, url (page on SecDB), source, source_url (original advisory), title, summary, description, solution, severity, published, modified, rights - cves: identifiers of the linked CVEs. Use `vulnerability_info`, `vulnerability_score`, or `kev_check` for their details - cvss: each with `cve_id`, `version`, `score`, `severity`, and `vector`. An entry with a null `cve_id` refers to the whole advisory; the others refer to that CVE - cwe: each with `id`, `name`, and `url` - packages: each with `purl`, `status` (for example `affected` or `fixed`), `vers` (versions as a VERS range, for example `vers:maven/>=2.0.0\|<2.0.11`), and `remediation`. It is `null` when the packages could not be read, which does not mean that no package is affected - products: each with `vendor`, `product`, `version`, `fixed_in`, `status`, `text`, `cpe22`, and `cpe23` - tags, impacts Fields that SecDB does not have for the advisory are `null` or empty. ## LLM usage guidelines - Do not guess advisory IDs: use the IDs returned by other tools or provided by the user. - If the advisory is not found, try `vulnerability_search` before saying that it do	Get detailed information about a specific security advisory. ## What this tool does Retrieves a security advisory (for example RHSA, DSA, USN, GHSA) from SecDB, including title, publication date, severity, summary, description, linked CVEs, CVSS metrics, weaknesses, and the affected and fixed packages and products. ## When to use this tool Use this tool when the user asks: - "Give me details about RHSA-2026:1234." - "Which CVEs are fixed by this advisory?" - "Which package versions are affected, and which version fixes them?" For a CVE, use `vulnerability_info`. If the exact advisory ID is not known, use `vulnerability_search` with `type` set to `advisory`. ## Inputs - advisory_id: exact advisory identifier (e.g. `RHSA-2026:1234`, `GHSA-xxxx-xxxx-xxxx`). ## Outputs - advisory_id, url (page on SecDB), source, source_url (original advisory), title, summary, description, solution, severity, published, modified, rights - cves: identifiers of the linked CVEs. Use `vulnerability_info`, `vulnerability_score`, or `kev_check` for their details - cvss: each with `cve_id`, `version`, `score`, `severity`, and `vector`. An entry with a null `cve_id` refers to the whole advisory; the others refer to that CVE - cwe: each with `id`, `name`, and `url` - packages: each with `purl`, `status` (for example `affected` or `fixed`), `vers` (versions as a VERS range, for example `vers:maven/>=2.0.0\|<2.0.11`), and `remediation`. It is `null` when the packages could not be read, which does not mean that no package is affected - products: each with `vendor`, `product`, `version`, `fixed_in`, `status`, `text`, `cpe22`, and `cpe23` - tags, impacts Fields that SecDB does not have for the advisory are `null` or empty. ## LLM usage guidelines - Do not guess advisory IDs: use the IDs returned by other tools or provided by the user. - If the advisory is not found, try `vulnerability_search` before saying that it do	No	Yes	Yes	No
`attack_info`Get information about a MITRE ATT&CK technique and the weaknesses and vulnerabilities linked to it through CAPEC. ## What this tool does Returns the name, description, tactics and platforms of an ATT&CK technique (Enterprise, Mobile or ICS), its parent technique or sub-techniques, the CAPEC attack patterns mapped to it, the weaknesses (CWE) exploited by those attack patterns, and the number of CVEs with those weaknesses. A parent technique also includes what is mapped to its sub-techniques. ## When to use this tool Use this tool when the user asks: - "What is T1574?" - "Which weaknesses or attack patterns are related to this technique?" - "How many vulnerabilities could be linked to this technique?" ## Inputs - technique_id: ATT&CK technique identifier (`T1574`, `T1574.010`, `1574.010` or `T1574/010`). ## Outputs - `id`, `name` (with the parent technique name for a sub-technique), `domain`, `description` - `tactics`: each with `id` and `name` - `platforms`: list of platforms - `parent_id`, `subtechniques` (each with `id` and `name`) - `deprecated`, `revoked`, `revoked_by` (the technique that replaces a revoked one) - `capec`: attack patterns, each with `id`, `name`, `direct` and `via` - `weaknesses`: CWE, each with `id`, `name`, `direct` and `via` - `cve_count`: number of CVEs with these weaknesses - `url`: link to the technique on SecDB, `mitre_url`: link to the technique on attack.mitre.org ## LLM usage guidelines - `direct` is `true` when CAPEC maps the attack pattern to this technique; `via` lists the sub-techniques it comes from. - The link to CVEs is derived from the weaknesses: a CVE in `cve_count` is not known to be exploited with this technique. Say so when you report it. - If `revoked` is `true` and `revoked_by` is set, call this tool again with `revoked_by` for the current technique. - For the CVEs themselves, search on SecDB from `url` (Vulnerabilities tab), or use `cwe_info` and `vulnerability_search` with the weaknesses.	Get information about a MITRE ATT&CK technique and the weaknesses and vulnerabilities linked to it through CAPEC. ## What this tool does Returns the name, description, tactics and platforms of an ATT&CK technique (Enterprise, Mobile or ICS), its parent technique or sub-techniques, the CAPEC attack patterns mapped to it, the weaknesses (CWE) exploited by those attack patterns, and the number of CVEs with those weaknesses. A parent technique also includes what is mapped to its sub-techniques. ## When to use this tool Use this tool when the user asks: - "What is T1574?" - "Which weaknesses or attack patterns are related to this technique?" - "How many vulnerabilities could be linked to this technique?" ## Inputs - technique_id: ATT&CK technique identifier (`T1574`, `T1574.010`, `1574.010` or `T1574/010`). ## Outputs - `id`, `name` (with the parent technique name for a sub-technique), `domain`, `description` - `tactics`: each with `id` and `name` - `platforms`: list of platforms - `parent_id`, `subtechniques` (each with `id` and `name`) - `deprecated`, `revoked`, `revoked_by` (the technique that replaces a revoked one) - `capec`: attack patterns, each with `id`, `name`, `direct` and `via` - `weaknesses`: CWE, each with `id`, `name`, `direct` and `via` - `cve_count`: number of CVEs with these weaknesses - `url`: link to the technique on SecDB, `mitre_url`: link to the technique on attack.mitre.org ## LLM usage guidelines - `direct` is `true` when CAPEC maps the attack pattern to this technique; `via` lists the sub-techniques it comes from. - The link to CVEs is derived from the weaknesses: a CVE in `cve_count` is not known to be exploited with this technique. Say so when you report it. - If `revoked` is `true` and `revoked_by` is set, call this tool again with `revoked_by` for the current technique. - For the CVEs themselves, search on SecDB from `url` (Vulnerabilities tab), or use `cwe_info` and `vulnerability_search` with the weaknesses.	No	Yes	Yes	No
`cpe_search`Find the CPE vendor and product names that SecDB uses for a product, with the number of CVEs of each one. ## What this tool does Searches the vendor and product names in the CPE configurations of the CVEs, marked as vulnerable. Every result can be passed to `product_vulnerabilities`. Results go from the most to the least CVEs. ## When to use this tool Use this tool when the user asks: - "What is the CPE name of Apache HTTP Server?" - "Which Fortinet products have known CVEs?" Use it before `product_vulnerabilities` when the exact names are not known. For open source dependencies, use `purl_audit`. ## Inputs - query: words to search in the vendor and product names, for example `apache http server`. Every word must match the vendor or the product. - vendor: exact CPE vendor name, to search only its products. - part: `a` (application), `o` (operating system), or `h` (hardware). - limit: maximum number of results to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page - results: each with `vendor`, `product`, `parts`, `cve_count` - note: present when nothing matches ## LLM usage guidelines - When several products match, show them to the user or use the closest one and say which one you chose. Do not merge them. - `cve_count` shows how many CVEs have the name, not how relevant it is. - No result does not mean that the product has no CVEs: try fewer or different words, or `vulnerability_search`.	Find the CPE vendor and product names that SecDB uses for a product, with the number of CVEs of each one. ## What this tool does Searches the vendor and product names in the CPE configurations of the CVEs, marked as vulnerable. Every result can be passed to `product_vulnerabilities`. Results go from the most to the least CVEs. ## When to use this tool Use this tool when the user asks: - "What is the CPE name of Apache HTTP Server?" - "Which Fortinet products have known CVEs?" Use it before `product_vulnerabilities` when the exact names are not known. For open source dependencies, use `purl_audit`. ## Inputs - query: words to search in the vendor and product names, for example `apache http server`. Every word must match the vendor or the product. - vendor: exact CPE vendor name, to search only its products. - part: `a` (application), `o` (operating system), or `h` (hardware). - limit: maximum number of results to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page - results: each with `vendor`, `product`, `parts`, `cve_count` - note: present when nothing matches ## LLM usage guidelines - When several products match, show them to the user or use the closest one and say which one you chose. Do not merge them. - `cve_count` shows how many CVEs have the name, not how relevant it is. - No result does not mean that the product has no CVEs: try fewer or different words, or `vulnerability_search`.	No	Yes	Yes	No
`cvss_explain`Calculate the score of any CVSS vector string and explain it in natural language. ## What this tool does Takes a CVSS vector string, not tied to a specific CVE, and returns its version, base score, severity, and a human-readable explanation. ## When to use this tool Use this tool when the user: - provides a CVSS vector and asks what it means - wants to see how the score changes when a metric changes - has adjusted a vector for their own environment For the official CVSS of a CVE, use `vulnerability_score`. ## Inputs - vector_string: CVSS vector string, e.g. `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. ## Outputs - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain`: human-readable explanation of the vector ## LLM usage guidelines - Never calculate CVSS scores by hand: use this tool.	Calculate the score of any CVSS vector string and explain it in natural language. ## What this tool does Takes a CVSS vector string, not tied to a specific CVE, and returns its version, base score, severity, and a human-readable explanation. ## When to use this tool Use this tool when the user: - provides a CVSS vector and asks what it means - wants to see how the score changes when a metric changes - has adjusted a vector for their own environment For the official CVSS of a CVE, use `vulnerability_score`. ## Inputs - vector_string: CVSS vector string, e.g. `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. ## Outputs - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain`: human-readable explanation of the vector ## LLM usage guidelines - Never calculate CVSS scores by hand: use this tool.	No	Yes	Yes	No
`cwe_info`Get information about a specific weakness (CWE), its related attack patterns (CAPEC) and ATT&CK techniques. ## What this tool does Returns the name and description of a CWE, its type, the related CAPEC attack patterns, the ATT&CK techniques mapped to those attack patterns, and the number of CVEs linked to it, with how many of them are in the CISA KEV and EU KEV catalogs. ## When to use this tool Use this tool when the user asks: - "What is CWE-79?" - "Which attack patterns are related to this weakness?" - "Which ATT&CK techniques are related to this weakness?" - "How often is this weakness exploited in the wild?" ## Inputs - cwe_id: CWE identifier (`CWE-79` or `79`). ## Outputs - `id`, `name`, `type`, `description` - `capec`: related attack patterns, each with `id` and `name` - `attack`: ATT&CK techniques mapped to these attack patterns (active techniques only), each with `id`, `name` and `via` (the CAPEC it comes from) - `cve_count`: number of CVEs linked to this CWE - `cisa_kev_count`: how many of these CVEs are in the CISA KEV catalog - `eu_kev_count`: how many of these CVEs are in the EU KEV catalog - `kev_count`: how many of these CVEs are in at least one of the two catalogs - `url`: link to the CWE on SecDB ## LLM usage guidelines - Do not explain a CWE from memory when the user needs the official definition: use this tool. - Do not add `cisa_kev_count` and `eu_kev_count`: a CVE can be in both catalogs. Use `kev_count` for the total. - Use `attack_info` for the details of an ATT&CK technique.	Get information about a specific weakness (CWE), its related attack patterns (CAPEC) and ATT&CK techniques. ## What this tool does Returns the name and description of a CWE, its type, the related CAPEC attack patterns, the ATT&CK techniques mapped to those attack patterns, and the number of CVEs linked to it, with how many of them are in the CISA KEV and EU KEV catalogs. ## When to use this tool Use this tool when the user asks: - "What is CWE-79?" - "Which attack patterns are related to this weakness?" - "Which ATT&CK techniques are related to this weakness?" - "How often is this weakness exploited in the wild?" ## Inputs - cwe_id: CWE identifier (`CWE-79` or `79`). ## Outputs - `id`, `name`, `type`, `description` - `capec`: related attack patterns, each with `id` and `name` - `attack`: ATT&CK techniques mapped to these attack patterns (active techniques only), each with `id`, `name` and `via` (the CAPEC it comes from) - `cve_count`: number of CVEs linked to this CWE - `cisa_kev_count`: how many of these CVEs are in the CISA KEV catalog - `eu_kev_count`: how many of these CVEs are in the EU KEV catalog - `kev_count`: how many of these CVEs are in at least one of the two catalogs - `url`: link to the CWE on SecDB ## LLM usage guidelines - Do not explain a CWE from memory when the user needs the official definition: use this tool. - Do not add `cisa_kev_count` and `eu_kev_count`: a CVE can be in both catalogs. Use `kev_count` for the total. - Use `attack_info` for the details of an ATT&CK technique.	No	Yes	Yes	No
`epss_timeseries`Get the historical EPSS time series for a specific CVE. ## What this tool does Returns the historical EPSS score, percentile, and model version available for a CVE across time, ordered by date. Useful for analyzing how exploitability likelihood has evolved over time. ## When to use this tool Use this tool when the user asks about: - EPSS trend over time - how exploitability probability changed - whether EPSS spiked or dropped - historical comparison of risk If the user only wants the current EPSS score, use `vulnerability_score` instead. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - days: optional number of days of history to return, counting back from today (default 365, maximum 3650). ## Outputs - series: array of objects, each containing: - `date`: measurement date in ISO format - `score`: EPSS score, as a percentage (`94.36` means 94.36%) - `percentile`: EPSS percentile, as a percentage - `model`: EPSS model version ## LLM usage guidelines - Never guess EPSS values-use this tool for all EPSS time-series questions. - If `cve_id` is malformed or incomplete, ask the user to correct it before calling. - If the user mentions multiple CVEs, call the tool once per CVE as needed. - Request a longer `days` window only when the user needs it: a full history is very large. - If no historical data is available, the tool returns an empty series: state that no EPSS history was found.	Get the historical EPSS time series for a specific CVE. ## What this tool does Returns the historical EPSS score, percentile, and model version available for a CVE across time, ordered by date. Useful for analyzing how exploitability likelihood has evolved over time. ## When to use this tool Use this tool when the user asks about: - EPSS trend over time - how exploitability probability changed - whether EPSS spiked or dropped - historical comparison of risk If the user only wants the current EPSS score, use `vulnerability_score` instead. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - days: optional number of days of history to return, counting back from today (default 365, maximum 3650). ## Outputs - series: array of objects, each containing: - `date`: measurement date in ISO format - `score`: EPSS score, as a percentage (`94.36` means 94.36%) - `percentile`: EPSS percentile, as a percentage - `model`: EPSS model version ## LLM usage guidelines - Never guess EPSS values-use this tool for all EPSS time-series questions. - If `cve_id` is malformed or incomplete, ask the user to correct it before calling. - If the user mentions multiple CVEs, call the tool once per CVE as needed. - Request a longer `days` window only when the user needs it: a full history is very large. - If no historical data is available, the tool returns an empty series: state that no EPSS history was found.	No	Yes	Yes	No
`feed_report`Run a public ZEN SecDB feed report. ## What this tool does Executes a predefined report on ZEN SecDB public feed data and returns structured results for analytics, trends, distributions, and top-N summaries. Supported reports can cover public datasets such as: - CVEs - security advisories - EPSS - weaknesses - CPE vendors and products - exploit references - sightings and IOC-related data Use `feed_report_catalog` to discover the list of available reports and their supported input parameters. ## When to use this tool Use this tool when the user asks about: - distributions, trends, or counts across public vulnerability data - top CVEs, top weaknesses, top vendors, or similar rankings - timeline-based summaries such as yearly or monthly trends - aggregated views over public SecDB feed data Do not use this tool when the user asks for details about a single CVE, advisory, or exploit. Use the dedicated lookup tools instead. ## Inputs - report_id: identifier of the report to execute - filters: optional object with report-specific filters - limit: optional maximum number of results to return, when supported by the selected report ## Outputs - report_id: executed report identifier - filters: applied filters - data: structured report rows or aggregated values ## LLM usage guidelines - Use `feed_report_catalog` when you need to discover which public reports are available or which parameters they support. - Do not guess report IDs-use the catalog when uncertain. - Use only the filters listed in the catalog: a report can ignore any other filter without an error, and return unfiltered data. - Use `data` for structured follow-up analysis, comparisons, or tool chaining. - If the selected report does not exist, return a clear not-found error instead of guessing an alternative.	Run a public ZEN SecDB feed report. ## What this tool does Executes a predefined report on ZEN SecDB public feed data and returns structured results for analytics, trends, distributions, and top-N summaries. Supported reports can cover public datasets such as: - CVEs - security advisories - EPSS - weaknesses - CPE vendors and products - exploit references - sightings and IOC-related data Use `feed_report_catalog` to discover the list of available reports and their supported input parameters. ## When to use this tool Use this tool when the user asks about: - distributions, trends, or counts across public vulnerability data - top CVEs, top weaknesses, top vendors, or similar rankings - timeline-based summaries such as yearly or monthly trends - aggregated views over public SecDB feed data Do not use this tool when the user asks for details about a single CVE, advisory, or exploit. Use the dedicated lookup tools instead. ## Inputs - report_id: identifier of the report to execute - filters: optional object with report-specific filters - limit: optional maximum number of results to return, when supported by the selected report ## Outputs - report_id: executed report identifier - filters: applied filters - data: structured report rows or aggregated values ## LLM usage guidelines - Use `feed_report_catalog` when you need to discover which public reports are available or which parameters they support. - Do not guess report IDs-use the catalog when uncertain. - Use only the filters listed in the catalog: a report can ignore any other filter without an error, and return unfiltered data. - Use `data` for structured follow-up analysis, comparisons, or tool chaining. - If the selected report does not exist, return a clear not-found error instead of guessing an alternative.	No	Yes	Yes	No
`feed_report_catalog`List available public ZEN SecDB feed reports. ## What this tool does Returns the catalog of available ZEN SecDB public feed reports, including their identifiers, descriptions, and supported input parameters. This tool helps discover which reports can be executed through `feed_report`. ## When to use this tool Use this tool when: - the user asks what public reports are available - you need to discover the correct report ID before running a report - you need to inspect supported filters or input parameters - you are unsure which report best matches the user request ## Inputs This tool does not require any input. ## Outputs - reports: array of report definitions, each containing: - `report_id`: report identifier - `title`: human-readable report title - `description`: short explanation of what the report returns - `input_schema`: optional JSON schema describing supported input parameters ## LLM usage guidelines - Use this tool before `feed_report` whenever the correct report ID or supported parameters are not already known. - Do not invent report IDs or parameters not present in the catalog. - Prefer the most specific matching report for the user request. - When useful, briefly summarize the most relevant available reports before calling `feed_report`.	List available public ZEN SecDB feed reports. ## What this tool does Returns the catalog of available ZEN SecDB public feed reports, including their identifiers, descriptions, and supported input parameters. This tool helps discover which reports can be executed through `feed_report`. ## When to use this tool Use this tool when: - the user asks what public reports are available - you need to discover the correct report ID before running a report - you need to inspect supported filters or input parameters - you are unsure which report best matches the user request ## Inputs This tool does not require any input. ## Outputs - reports: array of report definitions, each containing: - `report_id`: report identifier - `title`: human-readable report title - `description`: short explanation of what the report returns - `input_schema`: optional JSON schema describing supported input parameters ## LLM usage guidelines - Use this tool before `feed_report` whenever the correct report ID or supported parameters are not already known. - Do not invent report IDs or parameters not present in the catalog. - Prefer the most specific matching report for the user request. - When useful, briefly summarize the most relevant available reports before calling `feed_report`.	No	Yes	Yes	No
`kev_check`Check whether one or more CVEs are listed in the CISA KEV or EU KEV catalogs of known exploited vulnerabilities. ## What this tool does For each CVE, returns whether it is in a KEV catalog and, if so, the dates, the known use in ransomware campaigns, and the threat actors reported by the EU catalog. ## When to use this tool Use this tool when the user asks: - "Is this CVE in CISA KEV?" - "Which of these CVEs are known to be exploited?" - to prioritize a list of CVEs For a single CVE, this is lighter than `vulnerability_info`. To find the entries of a catalog by date, vendor, or product, use `kev_list`. ## Inputs - cve_ids: list of CVE identifiers (`CVE-YYYY-NNNNN`), up to 100. ## Outputs - results: one object for each CVE, containing: - `cve_id` - `in_kev`: whether the CVE is in at least one KEV catalog - when `in_kev` is true: `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date`, `euvd_id`, `eu_exploitation_type`, `eu_threat_actors_exploiting` ## LLM usage guidelines - Send all the CVEs in one call instead of calling the tool once per CVE. - `in_kev: false` means that the CVE is not in these catalogs, not that it is not exploited: use `sightings_search` for other evidence. - `in_kev: false` does not confirm that the CVE exists: use `vulnerability_score` or `vulnerability_info` to check it.	Check whether one or more CVEs are listed in the CISA KEV or EU KEV catalogs of known exploited vulnerabilities. ## What this tool does For each CVE, returns whether it is in a KEV catalog and, if so, the dates, the known use in ransomware campaigns, and the threat actors reported by the EU catalog. ## When to use this tool Use this tool when the user asks: - "Is this CVE in CISA KEV?" - "Which of these CVEs are known to be exploited?" - to prioritize a list of CVEs For a single CVE, this is lighter than `vulnerability_info`. To find the entries of a catalog by date, vendor, or product, use `kev_list`. ## Inputs - cve_ids: list of CVE identifiers (`CVE-YYYY-NNNNN`), up to 100. ## Outputs - results: one object for each CVE, containing: - `cve_id` - `in_kev`: whether the CVE is in at least one KEV catalog - when `in_kev` is true: `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date`, `euvd_id`, `eu_exploitation_type`, `eu_threat_actors_exploiting` ## LLM usage guidelines - Send all the CVEs in one call instead of calling the tool once per CVE. - `in_kev: false` means that the CVE is not in these catalogs, not that it is not exploited: use `sightings_search` for other evidence. - `in_kev: false` does not confirm that the CVE exists: use `vulnerability_score` or `vulnerability_info` to check it.	No	Yes	Yes	No
`kev_list`List the entries of the CISA KEV and EU KEV catalogs of known exploited vulnerabilities, most recent first. ## What this tool does Returns the CVEs in the catalogs, filtered by listing date, catalog, vendor, product, and known use in ransomware campaigns. ## When to use this tool Use this tool when the user asks: - "What was added to KEV this week?" - "Which Fortinet vulnerabilities are known to be exploited?" - "Which KEV entries are used in ransomware campaigns?" To check CVEs that you already know, use `kev_check`. ## Inputs - since: only return entries listed since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included). - catalog: `cisa` or `eu` (default: both). It also selects the date used by `since` and by the order of the results. - vendor: part of the vendor name, for example `fortinet`. - product: part of the product name, for example `fortios`. - ransomware: `true` to only return entries with known use in ransomware campaigns, `false` for the others. - limit: maximum number of entries to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page - entries: each with `cve_id`, `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `first_listed_date`, `first_listed_by`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date` ## LLM usage guidelines - Without `catalog`, `since` uses `first_listed_date`: a CVE already in CISA KEV that has just been added to EU KEV does not appear. To see the recent entries of a catalog, set `catalog`. - When `total_results` is greater than the returned entries, say so before drawing conclusions. - An empty list does not mean that nothing is exploited: the catalogs only contain confirmed cases. Use `sightings_search` for other evidence. - For the score of the CVEs, use `vulnerability_score`.	List the entries of the CISA KEV and EU KEV catalogs of known exploited vulnerabilities, most recent first. ## What this tool does Returns the CVEs in the catalogs, filtered by listing date, catalog, vendor, product, and known use in ransomware campaigns. ## When to use this tool Use this tool when the user asks: - "What was added to KEV this week?" - "Which Fortinet vulnerabilities are known to be exploited?" - "Which KEV entries are used in ransomware campaigns?" To check CVEs that you already know, use `kev_check`. ## Inputs - since: only return entries listed since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included). - catalog: `cisa` or `eu` (default: both). It also selects the date used by `since` and by the order of the results. - vendor: part of the vendor name, for example `fortinet`. - product: part of the product name, for example `fortios`. - ransomware: `true` to only return entries with known use in ransomware campaigns, `false` for the others. - limit: maximum number of entries to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page - entries: each with `cve_id`, `in_cisa`, `in_eu`, `vendor`, `product`, `vulnerability_name`, `ransomware`, `first_listed_date`, `first_listed_by`, `cisa_added_date`, `cisa_due_date`, `eu_reported_date` ## LLM usage guidelines - Without `catalog`, `since` uses `first_listed_date`: a CVE already in CISA KEV that has just been added to EU KEV does not appear. To see the recent entries of a catalog, set `catalog`. - When `total_results` is greater than the returned entries, say so before drawing conclusions. - An empty list does not mean that nothing is exploited: the catalogs only contain confirmed cases. Use `sightings_search` for other evidence. - For the score of the CVEs, use `vulnerability_score`.	No	Yes	Yes	No
`linux_audit`Perform a Linux package vulnerability audit using SecDB. ## What this tool does Analyzes the installed packages of a Linux system-identified by OS and OS version-and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided by the user. ## When to use this tool Use this tool when the user wants to determine: - whether installed packages contain known vulnerabilities - whether a host, VM, container, or base image is affected by security advisories - which packages require patching or upgrading If the user does not know the valid values for `os` or `version`, first call the `linux_os` tool to retrieve the exact supported combinations. ## Inputs - os: Linux distribution identifier supported by SecDB (use `linux_os` to obtain allowed values). - version: OS version or codename corresponding to the selected distribution, exactly as returned by `linux_os` (for example `focal`, not `20.04`). Any other value is rejected with the list of supported values. - packages: list of installed packages, one per line, generated using the appropriate system command: ### For RPM-based distributions (RHEL, CentOS, Rocky, Alma, SUSE) rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ### For DEB-based distributions (Ubuntu, Debian) dpkg-query -W -f='${Package} ${Version} ${Architecture}\n' ### For Alpine Linux apk list -I ### For Slackware ls -1 /var/log/packages/ The raw output of these commands can be passed directly as the `packages` input (one package per line). ... python3 3.12.3-0ubuntu2.1 amd64 systemd 255.4-1ubuntu8.10 amd64 tmux 3.4-1ubuntu0.1 amd64 ... ## Outputs - report: structured objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - summary: Markdown summary including vulnerable packages, total CVEs, and severity breakdown. ## LLM usage guidelines - Never guess	Perform a Linux package vulnerability audit using SecDB. ## What this tool does Analyzes the installed packages of a Linux system-identified by OS and OS version-and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided by the user. ## When to use this tool Use this tool when the user wants to determine: - whether installed packages contain known vulnerabilities - whether a host, VM, container, or base image is affected by security advisories - which packages require patching or upgrading If the user does not know the valid values for `os` or `version`, first call the `linux_os` tool to retrieve the exact supported combinations. ## Inputs - os: Linux distribution identifier supported by SecDB (use `linux_os` to obtain allowed values). - version: OS version or codename corresponding to the selected distribution, exactly as returned by `linux_os` (for example `focal`, not `20.04`). Any other value is rejected with the list of supported values. - packages: list of installed packages, one per line, generated using the appropriate system command: ### For RPM-based distributions (RHEL, CentOS, Rocky, Alma, SUSE) rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ### For DEB-based distributions (Ubuntu, Debian) dpkg-query -W -f='${Package} ${Version} ${Architecture}\n' ### For Alpine Linux apk list -I ### For Slackware ls -1 /var/log/packages/ The raw output of these commands can be passed directly as the `packages` input (one package per line). ... python3 3.12.3-0ubuntu2.1 amd64 systemd 255.4-1ubuntu8.10 amd64 tmux 3.4-1ubuntu0.1 amd64 ... ## Outputs - report: structured objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - summary: Markdown summary including vulnerable packages, total CVEs, and severity breakdown. ## LLM usage guidelines - Never guess	No	Yes	Yes	No
`linux_os`List supported Linux operating systems and their corresponding versions for use with the `linux_audit` tool. ## What this tool does Returns the supported OS/version pairs in `supported`, each in the form: {"os":"name", "versions":["version or codename"]} This allows the LLM and the user to know exactly which inputs are valid for the `linux_audit` tool. ## When to use this tool Use this tool when: - the user does not know which OS names or versions are supported - the user provides unclear or ambiguous OS information - you need to validate `os`/`version` before performing a Linux audit This tool should typically be called before `linux_audit` whenever parameters are uncertain. ## Inputs This tool does not require any input. ## Outputs - supported: array of objects, each containing: - os: supported Linux distribution identifier - versions: corresponding list of supported release or codename Example: { "supported": [ {"os": "ubuntu", "versions": ["noble","focal"]}, {"os": "debian", "versions": ["bookworm","sid"]}, {"os": "redhat", "versions": ["redhat-9.0"]} ] } ## LLM usage guidelines - Use this tool to validate or suggest correct OS/version combinations before calling `linux_audit`. - If the user provides invalid or misspelled OS names, retrieve the official list here and ask them to select one. - Do not guess operating system identifiers-always rely on this tool to confirm correctness.	List supported Linux operating systems and their corresponding versions for use with the `linux_audit` tool. ## What this tool does Returns the supported OS/version pairs in `supported`, each in the form: {"os":"name", "versions":["version or codename"]} This allows the LLM and the user to know exactly which inputs are valid for the `linux_audit` tool. ## When to use this tool Use this tool when: - the user does not know which OS names or versions are supported - the user provides unclear or ambiguous OS information - you need to validate `os`/`version` before performing a Linux audit This tool should typically be called before `linux_audit` whenever parameters are uncertain. ## Inputs This tool does not require any input. ## Outputs - supported: array of objects, each containing: - os: supported Linux distribution identifier - versions: corresponding list of supported release or codename Example: { "supported": [ {"os": "ubuntu", "versions": ["noble","focal"]}, {"os": "debian", "versions": ["bookworm","sid"]}, {"os": "redhat", "versions": ["redhat-9.0"]} ] } ## LLM usage guidelines - Use this tool to validate or suggest correct OS/version combinations before calling `linux_audit`. - If the user provides invalid or misspelled OS names, retrieve the official list here and ask them to select one. - Do not guess operating system identifiers-always rely on this tool to confirm correctness.	No	Yes	Yes	No
`package_info`List the security advisories known for a package, with the affected and fixed versions. ## What this tool does Returns the advisories of a package across all its versions, most recent first. This covers more ecosystems than `purl_audit`, for example `github`, `cpan`, `apache`, and `freebsd`. ## When to use this tool Use this tool when the user asks: - "Which vulnerabilities has this package had?" - "Which version fixes this vulnerability?" - "Which version should I upgrade to?" To check whether a specific version is vulnerable, use `purl_audit` or `linux_audit`: this tool does not evaluate versions. ## Inputs - purl: Package URL. The version is ignored. For Linux packages, add the `distro` qualifier to limit the results to one release, for example `pkg:deb/ubuntu/curl?distro=noble`. - limit: maximum number of advisories to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page: advisories for the package across all pages - advisories: each with `advisory_id`, `title`, `severity`, `published`, `cves`, `status`, `affected`, `fixed_versions` - affected: version ranges, each with `versions` and, for Linux packages, `distro` - fixed_versions: each with `version` and, for Linux packages, `distro`. A version is either reported as fixed by the advisory or the exclusive upper bound of an affected range ## LLM usage guidelines - When `total_results` is 0, say that SecDB has no advisories for this package name, not that the package is safe. Names must match exactly. - To recommend an upgrade, consider all the advisories and check the resulting version with `purl_audit` when its ecosystem is supported. - `status` can include `malicious`: tell the user to remove the package instead of upgrading it. - If `fixed_versions` is empty, say that no fix is known. Do not guess a version.	List the security advisories known for a package, with the affected and fixed versions. ## What this tool does Returns the advisories of a package across all its versions, most recent first. This covers more ecosystems than `purl_audit`, for example `github`, `cpan`, `apache`, and `freebsd`. ## When to use this tool Use this tool when the user asks: - "Which vulnerabilities has this package had?" - "Which version fixes this vulnerability?" - "Which version should I upgrade to?" To check whether a specific version is vulnerable, use `purl_audit` or `linux_audit`: this tool does not evaluate versions. ## Inputs - purl: Package URL. The version is ignored. For Linux packages, add the `distro` qualifier to limit the results to one release, for example `pkg:deb/ubuntu/curl?distro=noble`. - limit: maximum number of advisories to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page: advisories for the package across all pages - advisories: each with `advisory_id`, `title`, `severity`, `published`, `cves`, `status`, `affected`, `fixed_versions` - affected: version ranges, each with `versions` and, for Linux packages, `distro` - fixed_versions: each with `version` and, for Linux packages, `distro`. A version is either reported as fixed by the advisory or the exclusive upper bound of an affected range ## LLM usage guidelines - When `total_results` is 0, say that SecDB has no advisories for this package name, not that the package is safe. Names must match exactly. - To recommend an upgrade, consider all the advisories and check the resulting version with `purl_audit` when its ecosystem is supported. - `status` can include `malicious`: tell the user to remove the package instead of upgrading it. - If `fixed_versions` is empty, say that no fix is known. Do not guess a version.	No	Yes	Yes	No
`product_vulnerabilities`List the CVEs of a product by its CPE vendor and product names, with the affected version ranges. ## What this tool does Returns the CVEs whose CPE configuration marks the product as vulnerable, most recent first. Use it for assets that have no Package URL, such as appliances, operating systems, and commercial software. ## When to use this tool Use this tool when the user asks: - "Which CVEs affect FortiOS?" - "What are the latest vulnerabilities of this product?" - "Is this product version affected by a known CVE?" For open source dependencies, use `purl_audit`. If the CPE names are not known, use `cpe_search` first. ## Inputs - vendor: CPE vendor name, for example `fortinet`. - product: CPE product name, for example `fortios`. - limit: maximum number of CVEs to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page: CVEs for the product across all pages - cves: each with `cve_id`, `published`, `severity`, `score`, `description`, `affected_versions` - note: present when no CVE matches ## LLM usage guidelines - This tool does not filter by version: compare the user's version with `affected_versions`, and say that the comparison is yours. An entry of `all` means that the configuration has no version limits. - When `total_results` is greater than the returned CVEs, say so before drawing conclusions about a version. - When `total_results` is 0, do not say that the product is safe: the vendor or product name may differ from the CPE one. Use `cpe_search` to find it.	List the CVEs of a product by its CPE vendor and product names, with the affected version ranges. ## What this tool does Returns the CVEs whose CPE configuration marks the product as vulnerable, most recent first. Use it for assets that have no Package URL, such as appliances, operating systems, and commercial software. ## When to use this tool Use this tool when the user asks: - "Which CVEs affect FortiOS?" - "What are the latest vulnerabilities of this product?" - "Is this product version affected by a known CVE?" For open source dependencies, use `purl_audit`. If the CPE names are not known, use `cpe_search` first. ## Inputs - vendor: CPE vendor name, for example `fortinet`. - product: CPE product name, for example `fortios`. - limit: maximum number of CVEs to return (default 25, maximum 100). - page: page of results to return (default 1). ## Outputs - total_results, total_pages, current_page: CVEs for the product across all pages - cves: each with `cve_id`, `published`, `severity`, `score`, `description`, `affected_versions` - note: present when no CVE matches ## LLM usage guidelines - This tool does not filter by version: compare the user's version with `affected_versions`, and say that the comparison is yours. An entry of `all` means that the configuration has no version limits. - When `total_results` is greater than the returned CVEs, say so before drawing conclusions about a version. - When `total_results` is 0, do not say that the product is safe: the vendor or product name may differ from the CPE one. Use `cpe_search` to find it.	No	Yes	Yes	No
`purl_audit`Perform a software package vulnerability audit using SecDB. ## What this tool does Analyzes a list of software packages identified by PURL (Package URL) and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided. ## When to use this tool Use this tool when the user wants to determine: - whether application dependencies contain known vulnerabilities - whether a project is affected by security advisories - which packages require patching or upgrading ## Supported ecosystems - npm - Node.js packages (e.g. pkg:npm/lodash@4.17.21) - maven - Java/JVM packages (e.g. pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1) - pypi - Python packages (e.g. pkg:pypi/django@4.2.0) - gem - Ruby gems (e.g. pkg:gem/rails@7.0.0) - cargo - Rust crates (e.g. pkg:cargo/openssl-src@111.10) - nuget - .NET packages (e.g. pkg:nuget/Newtonsoft.Json@13.0.1) - golang - Go modules (e.g. pkg:golang/github.com/gin-gonic/gin@1.9.1) - composer - PHP packages (e.g. pkg:composer/symfony/symfony@6.4.0) - pub - Dart packages (e.g. pkg:pub/dio@5.4.0) - swift - Swift packages (e.g. pkg:swift/github.com/apple/swift-nio@2.65.0) - hex - Erlang and Elixir packages (e.g. pkg:hex/phoenix@1.7.0) ## Inputs - purls: list of Package URLs, one per entry. Generate them from your project manifest files: - Node.js: package.json / package-lock.json - Python: requirements.txt / Pipfile.lock / pyproject.toml - Ruby: Gemfile.lock - Go: go.mod / go.sum - Rust: Cargo.lock - PHP: composer.lock - Java: pom.xml / build.gradle - .NET: .csproj / packages.lock.json ## Outputs - report: structured JSON objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - summary*: Markdown summary including vulnerable packages, total CVEs, and severity br	Perform a software package vulnerability audit using SecDB. ## What this tool does Analyzes a list of software packages identified by PURL (Package URL) and returns vulnerability information plus a Markdown summary. The audit results are based exclusively on the package list provided. ## When to use this tool Use this tool when the user wants to determine: - whether application dependencies contain known vulnerabilities - whether a project is affected by security advisories - which packages require patching or upgrading ## Supported ecosystems - npm - Node.js packages (e.g. pkg:npm/lodash@4.17.21) - maven - Java/JVM packages (e.g. pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1) - pypi - Python packages (e.g. pkg:pypi/django@4.2.0) - gem - Ruby gems (e.g. pkg:gem/rails@7.0.0) - cargo - Rust crates (e.g. pkg:cargo/openssl-src@111.10) - nuget - .NET packages (e.g. pkg:nuget/Newtonsoft.Json@13.0.1) - golang - Go modules (e.g. pkg:golang/github.com/gin-gonic/gin@1.9.1) - composer - PHP packages (e.g. pkg:composer/symfony/symfony@6.4.0) - pub - Dart packages (e.g. pkg:pub/dio@5.4.0) - swift - Swift packages (e.g. pkg:swift/github.com/apple/swift-nio@2.65.0) - hex - Erlang and Elixir packages (e.g. pkg:hex/phoenix@1.7.0) ## Inputs - purls: list of Package URLs, one per entry. Generate them from your project manifest files: - Node.js: package.json / package-lock.json - Python: requirements.txt / Pipfile.lock / pyproject.toml - Ruby: Gemfile.lock - Go: go.mod / go.sum - Rust: Cargo.lock - PHP: composer.lock - Java: pom.xml / build.gradle - .NET: .csproj / packages.lock.json ## Outputs - report: structured JSON objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed. - summary*: Markdown summary including vulnerable packages, total CVEs, and severity br	No	Yes	Yes	No
`sightings_search`Search real-world vulnerability sightings in SecDB. ## What this tool does Retrieves information about where and how a vulnerability appears in the real world, including: - Exploit-DB references and PoCs - Scanner plugins (Nessus, OpenVAS/Greenbone) - Vendor advisories - Social/media references (Reddit, Mastodon, Bluesky) - MISP threat-intel sightings ## When to use this tool Use this tool when the user asks: - "Is this CVE exploited in the wild?" - "Is there a PoC or exploit available?" - "Does Nessus or OpenVAS have a plugin for this CVE?" - "Is this vulnerability being discussed online?" - "Show me all advisories/exploits for this CVE/product." ## Inputs Any of the following may be used: - cve_id: search by specific CVE - query: full-text search (name, product, advisory ID, exploit reference, etc.) - category: filter sightings by type (e.g., `exploit`, `nasl`, `advisory`, `scanner`, `poc`, `social`, `misp`) - status: filter by sighting state (`exploited`, `mitigated`, `seen`, `confirmed`, etc.) - since: only return sightings created since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included) - limit: maximum number of sightings to return (default 25, maximum 100) - page: page of results to return (default 1) ## Outputs - sightings: array of sightings, most recent first, typically containing: - `cve_id` - `status` - `category` - `reference` - `details` (object with additional structured data) - total_results, total_pages, current_page: use them to decide whether to ask for another `page` ## LLM usage guidelines - Use `cve_id` when the question targets a specific vulnerability. - Use `query` for broad or exploratory searches. - Only use valid enum values for `category` and `status`. - Use this tool instead of assuming exploitation, PoCs, or plugin availability. - Use `page` only when the user needs more than the first results. - For Metasploit modules, use `vulnerability_exploits`.	Search real-world vulnerability sightings in SecDB. ## What this tool does Retrieves information about where and how a vulnerability appears in the real world, including: - Exploit-DB references and PoCs - Scanner plugins (Nessus, OpenVAS/Greenbone) - Vendor advisories - Social/media references (Reddit, Mastodon, Bluesky) - MISP threat-intel sightings ## When to use this tool Use this tool when the user asks: - "Is this CVE exploited in the wild?" - "Is there a PoC or exploit available?" - "Does Nessus or OpenVAS have a plugin for this CVE?" - "Is this vulnerability being discussed online?" - "Show me all advisories/exploits for this CVE/product." ## Inputs Any of the following may be used: - cve_id: search by specific CVE - query: full-text search (name, product, advisory ID, exploit reference, etc.) - category: filter sightings by type (e.g., `exploit`, `nasl`, `advisory`, `scanner`, `poc`, `social`, `misp`) - status: filter by sighting state (`exploited`, `mitigated`, `seen`, `confirmed`, etc.) - since: only return sightings created since then: a period (`P7D`, `P1W`, `P3M`, `P1Y`) or a date (`2026-10-01`, included) - limit: maximum number of sightings to return (default 25, maximum 100) - page: page of results to return (default 1) ## Outputs - sightings: array of sightings, most recent first, typically containing: - `cve_id` - `status` - `category` - `reference` - `details` (object with additional structured data) - total_results, total_pages, current_page: use them to decide whether to ask for another `page` ## LLM usage guidelines - Use `cve_id` when the question targets a specific vulnerability. - Use `query` for broad or exploratory searches. - Only use valid enum values for `category` and `status`. - Use this tool instead of assuming exploitation, PoCs, or plugin availability. - Use `page` only when the user needs more than the first results. - For Metasploit modules, use `vulnerability_exploits`.	No	Yes	Yes	No
`ssvc_calculator`Compute CISA SSVC (Stakeholder-Specific Vulnerability Categorization) for a CVE. ## What this tool does Calculates the SSVC decision (Track, Track, Attend, Act) using: - exploitation status - technical impact - automatable exploitation - mission prevalence (user-provided) - public well-being impact (user-provided) This reflects CISA's official SSVC prioritization model. ## When to use this tool Use this tool when the user asks about: - how urgently a CVE should be remediated - CISA SSVC priority or risk category - a structured decision model for remediation ## Inputs - cve_id: the vulnerability to evaluate (`CVE-YYYY-NNNNN`) - mission_prevalence: `M`, `S`, or `E` (must be provided by the user) - public_well_being_impact: `M`, `A`, or `I` (must be provided by the user) ## Outputs - `decision`: one of Track, Track\, Attend, Act - `exploitation` - `technical_impact` - `automatable` - `mission_prevalence` - `public_well_being_impact` - `mission_and_well_being_impact_value` - `vector_string` - `summary`: Markdown explanation of the outcome ## LLM usage guidelines - Always ask the user for mission_prevalence (M/S/E) and public_well_being_impact** (M/A/I) before calling. - Never guess these values—SSVC depends on user context. - Use the `summary` to explain clearly why the decision was returned. - Combine with `vulnerability_score` or `sightings_search` if the user needs additional context.	Compute CISA SSVC (Stakeholder-Specific Vulnerability Categorization) for a CVE. ## What this tool does Calculates the SSVC decision (Track, Track, Attend, Act) using: - exploitation status - technical impact - automatable exploitation - mission prevalence (user-provided) - public well-being impact (user-provided) This reflects CISA's official SSVC prioritization model. ## When to use this tool Use this tool when the user asks about: - how urgently a CVE should be remediated - CISA SSVC priority or risk category - a structured decision model for remediation ## Inputs - cve_id: the vulnerability to evaluate (`CVE-YYYY-NNNNN`) - mission_prevalence: `M`, `S`, or `E` (must be provided by the user) - public_well_being_impact: `M`, `A`, or `I` (must be provided by the user) ## Outputs - `decision`: one of Track, Track\, Attend, Act - `exploitation` - `technical_impact` - `automatable` - `mission_prevalence` - `public_well_being_impact` - `mission_and_well_being_impact_value` - `vector_string` - `summary`: Markdown explanation of the outcome ## LLM usage guidelines - Always ask the user for mission_prevalence (M/S/E) and public_well_being_impact** (M/A/I) before calling. - Never guess these values—SSVC depends on user context. - Use the `summary` to explain clearly why the decision was returned. - Combine with `vulnerability_score` or `sightings_search` if the user needs additional context.	No	Yes	Yes	No
`vulnerability_attack`Get the weaknesses (CWE), attack patterns (CAPEC) and MITRE ATT&CK techniques linked to a specific CVE. ## What this tool does Follows the chain CVE → CWE → CAPEC → ATT&CK: returns the weaknesses of the CVE, the CAPEC attack patterns that exploit them, the ATT&CK techniques mapped to those attack patterns (active techniques only), and a summary of the ATT&CK tactics involved. ## When to use this tool Use this tool when the user asks: - "Which ATT&CK techniques are related to CVE-XYZ?" - "Which tactics could an attacker use with this vulnerability?" - "Which attack patterns exploit the weaknesses of this CVE?" ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - `cve_id`, `url`: link to the CVE on SecDB - `cwe`: weaknesses, each with `id`, `name` and `url` - `capec`: attack patterns, each with `id`, `name`, `via` (the CWE it comes from) and `url` - `attack`: ATT&CK techniques, each with `id`, `name`, `tactics` (`id` and `name`), `via` (the CAPEC it comes from), `url` and `mitre_url` - `tactics`: ATT&CK tactics, each with `id`, `name` and `technique_count` ## LLM usage guidelines - The link is derived from the weaknesses of the CVE: it does not mean that the vulnerability is exploited with these techniques. Say "related to" or "could be linked to", never "exploited via". - Empty lists are normal: many weaknesses have no CAPEC attack pattern and many attack patterns have no ATT&CK technique. - For real-world exploitation use `kev_check`, `vulnerability_exploits` and `sightings_search`. - For the details of a technique or a weakness use `attack_info` or `cwe_info`.	Get the weaknesses (CWE), attack patterns (CAPEC) and MITRE ATT&CK techniques linked to a specific CVE. ## What this tool does Follows the chain CVE → CWE → CAPEC → ATT&CK: returns the weaknesses of the CVE, the CAPEC attack patterns that exploit them, the ATT&CK techniques mapped to those attack patterns (active techniques only), and a summary of the ATT&CK tactics involved. ## When to use this tool Use this tool when the user asks: - "Which ATT&CK techniques are related to CVE-XYZ?" - "Which tactics could an attacker use with this vulnerability?" - "Which attack patterns exploit the weaknesses of this CVE?" ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - `cve_id`, `url`: link to the CVE on SecDB - `cwe`: weaknesses, each with `id`, `name` and `url` - `capec`: attack patterns, each with `id`, `name`, `via` (the CWE it comes from) and `url` - `attack`: ATT&CK techniques, each with `id`, `name`, `tactics` (`id` and `name`), `via` (the CAPEC it comes from), `url` and `mitre_url` - `tactics`: ATT&CK tactics, each with `id`, `name` and `technique_count` ## LLM usage guidelines - The link is derived from the weaknesses of the CVE: it does not mean that the vulnerability is exploited with these techniques. Say "related to" or "could be linked to", never "exploited via". - Empty lists are normal: many weaknesses have no CAPEC attack pattern and many attack patterns have no ATT&CK technique. - For real-world exploitation use `kev_check`, `vulnerability_exploits` and `sightings_search`. - For the details of a technique or a weakness use `attack_info` or `cwe_info`.	No	Yes	Yes	No
`vulnerability_exploits`List the known exploits, proofs of concept, and detection templates for a specific CVE. ## What this tool does Returns the exploit maturity of a CVE and the related public material known to SecDB: - Metasploit modules - Exploit-DB entries - Nuclei templates - proofs of concept published on GitHub ## When to use this tool Use this tool when the user asks: - "Is there a public exploit for this CVE?" - "Is there a Metasploit module or a Nuclei template for this vulnerability?" - "How mature is the exploitation of this CVE?" For other evidence (scanner plugins, social media, MISP), use `sightings_search`. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - limit: maximum number of items to return for each kind of material (default 10, maximum 100). ## Outputs - exploit_maturity: `score`, `max`, and the `sources` that contribute to the score - metasploit: modules, each with `module`, `name`, `type` - exploitdb: entries, each with `id`, `description`, `type`, `platform`, `date_published` - nuclei: templates, each with `template`, `name`, `severity` - poc: repositories, each with `name`, `html_url`, `description` - totals: total number of items for each kind of material, before `limit` is applied ## LLM usage guidelines - Empty lists mean that SecDB knows no such material, not that the vulnerability cannot be exploited. - Report references and availability only: do not reproduce or write exploit code.	List the known exploits, proofs of concept, and detection templates for a specific CVE. ## What this tool does Returns the exploit maturity of a CVE and the related public material known to SecDB: - Metasploit modules - Exploit-DB entries - Nuclei templates - proofs of concept published on GitHub ## When to use this tool Use this tool when the user asks: - "Is there a public exploit for this CVE?" - "Is there a Metasploit module or a Nuclei template for this vulnerability?" - "How mature is the exploitation of this CVE?" For other evidence (scanner plugins, social media, MISP), use `sightings_search`. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - limit: maximum number of items to return for each kind of material (default 10, maximum 100). ## Outputs - exploit_maturity: `score`, `max`, and the `sources` that contribute to the score - metasploit: modules, each with `module`, `name`, `type` - exploitdb: entries, each with `id`, `description`, `type`, `platform`, `date_published` - nuclei: templates, each with `template`, `name`, `severity` - poc: repositories, each with `name`, `html_url`, `description` - totals: total number of items for each kind of material, before `limit` is applied ## LLM usage guidelines - Empty lists mean that SecDB knows no such material, not that the vulnerability cannot be exploited. - Report references and availability only: do not reproduce or write exploit code.	No	Yes	Yes	No
`vulnerability_history`Get the timeline of events for a specific CVE. ## What this tool does Returns the dated events known to SecDB for a CVE, most recent first: - published: publication of the CVE - nvd: NVD changes (CVSS, CPE, CWE, references, description) - advisory: security advisories that mention the CVE - nasl: NASL detection plugins that cover the CVE - cisa-kev, eu-kev: addition to a Known Exploited Vulnerabilities catalog - poc: public proof-of-concept repositories on GitHub - exploitdb: Exploit-DB entries - alias: public disclosure under a known name Every event carries the date of the event itself, not the date it reached SecDB. Sources without a date are not included. EPSS changes are not included: use `epss_timeseries`. ## When to use this tool Use this tool when the user asks: - "What changed on CVE-XYZ since last week?" - "When was this CVE added to KEV?" - "When did the first PoC or detection plugin appear?" For the current state of a CVE, use `vulnerability_info`. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - types: only return these event types (default: all). - since: only return events from this date, included (`YYYY-MM-DD`). ## Outputs - cve_id: CVE identifier. - returned: number of events returned. - counts: number of events for each type. It follows `since` but not `types`, so it also shows what `types` left out. - events: each with `type`, `timestamp`, and `change`. The fields of `change` depend on the type: - published: none - nvd: `source`, `event`, `action`, `type`, `old`, `new` - advisory: `advisory_type`, `advisory_id`, `advisory_severity`, `advisory_title` - nasl: `plugin_id`, `plugin_vendor`, `plugin_name` - cisa-kev: `vulnerability_name`, `due_date` - eu-kev: `vulnerability_name`, `patched_since` - poc: `name`, `description`, `url` - exploitdb: `id`, `description`, `file` - alias: `alias` ## LLM usage guidelines - T	Get the timeline of events for a specific CVE. ## What this tool does Returns the dated events known to SecDB for a CVE, most recent first: - published: publication of the CVE - nvd: NVD changes (CVSS, CPE, CWE, references, description) - advisory: security advisories that mention the CVE - nasl: NASL detection plugins that cover the CVE - cisa-kev, eu-kev: addition to a Known Exploited Vulnerabilities catalog - poc: public proof-of-concept repositories on GitHub - exploitdb: Exploit-DB entries - alias: public disclosure under a known name Every event carries the date of the event itself, not the date it reached SecDB. Sources without a date are not included. EPSS changes are not included: use `epss_timeseries`. ## When to use this tool Use this tool when the user asks: - "What changed on CVE-XYZ since last week?" - "When was this CVE added to KEV?" - "When did the first PoC or detection plugin appear?" For the current state of a CVE, use `vulnerability_info`. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - types: only return these event types (default: all). - since: only return events from this date, included (`YYYY-MM-DD`). ## Outputs - cve_id: CVE identifier. - returned: number of events returned. - counts: number of events for each type. It follows `since` but not `types`, so it also shows what `types` left out. - events: each with `type`, `timestamp`, and `change`. The fields of `change` depend on the type: - published: none - nvd: `source`, `event`, `action`, `type`, `old`, `new` - advisory: `advisory_type`, `advisory_id`, `advisory_severity`, `advisory_title` - nasl: `plugin_id`, `plugin_vendor`, `plugin_name` - cisa-kev: `vulnerability_name`, `due_date` - eu-kev: `vulnerability_name`, `patched_since` - poc: `name`, `description`, `url` - exploitdb: `id`, `description`, `file` - alias: `alias` ## LLM usage guidelines - T	No	Yes	Yes	No
`vulnerability_info`Get detailed information about a specific CVE. ## What this tool does Retrieves the full vulnerability record for a CVE from SecDB, including: - official description and summary - CVSS metrics (all versions available) - current EPSS score and percentile (if present) - CISA KEV details (if listed) - affected products - vendor/security advisories - weakness classification (CWE) - number of known Metasploit modules and Exploit-DB entries ## When to use this tool Use this tool when the user asks: - "Give me details about CVE-XYZ." - "Which products are affected by this vulnerability?" - "Show me advisories or references for this CVE." - "Explain what this vulnerability is and how serious it is." This tool is ideal for deep inspection of a single vulnerability. For multiple CVEs, call the tool once per CVE. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - cve_id, url, title, description, cna, status, published, modified, aliases - cwe: each with `id`, `name`, and `url` - cvss: one entry for each CVSS version available, with `version`, `score`, `severity`, and `vector` - epss: `score` and `percentile` (both as percentages) and `date`, or `null` - exploits: number of known `metasploit` modules and `exploitdb` entries - kev: `listed`, `in_cisa`, `in_eu`, `date` (first listing), `ransomware`, and `cisa` (`vendor`, `product`, `description`, `required_action`, `notes`, `added_date`, `due_date`, or `null`) - affected_products: each with `vendor`, `product`, `part`, `title`, and `url`, without versions - advisories: each with `id`, `source`, `severity`, and `url`. Use `advisory_info` for the details of an advisory ## LLM usage guidelines - Always prefer this tool when the user needs factual information about a specific CVE. - If multiple CVEs are mentioned, call the tool once per CVE. - Combine with: - `vulnerability_score` - to get the CVSS vector explained in natural la	Get detailed information about a specific CVE. ## What this tool does Retrieves the full vulnerability record for a CVE from SecDB, including: - official description and summary - CVSS metrics (all versions available) - current EPSS score and percentile (if present) - CISA KEV details (if listed) - affected products - vendor/security advisories - weakness classification (CWE) - number of known Metasploit modules and Exploit-DB entries ## When to use this tool Use this tool when the user asks: - "Give me details about CVE-XYZ." - "Which products are affected by this vulnerability?" - "Show me advisories or references for this CVE." - "Explain what this vulnerability is and how serious it is." This tool is ideal for deep inspection of a single vulnerability. For multiple CVEs, call the tool once per CVE. ## Inputs - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). ## Outputs - cve_id, url, title, description, cna, status, published, modified, aliases - cwe: each with `id`, `name`, and `url` - cvss: one entry for each CVSS version available, with `version`, `score`, `severity`, and `vector` - epss: `score` and `percentile` (both as percentages) and `date`, or `null` - exploits: number of known `metasploit` modules and `exploitdb` entries - kev: `listed`, `in_cisa`, `in_eu`, `date` (first listing), `ransomware`, and `cisa` (`vendor`, `product`, `description`, `required_action`, `notes`, `added_date`, `due_date`, or `null`) - affected_products: each with `vendor`, `product`, `part`, `title`, and `url`, without versions - advisories: each with `id`, `source`, `severity`, and `url`. Use `advisory_info` for the details of an advisory ## LLM usage guidelines - Always prefer this tool when the user needs factual information about a specific CVE. - If multiple CVEs are mentioned, call the tool once per CVE. - Combine with: - `vulnerability_score` - to get the CVSS vector explained in natural la	No	Yes	Yes	No
`vulnerability_score`Get CVSS and current EPSS score for one CVE, or for a list of CVEs in a single call. ## What this tool does Returns a full risk snapshot for a CVE, including: - CVSS version - CVSS base score - CVSS severity - CVSS vector string - human-readable explanation of the CVSS vector - current EPSS score The field `cvss_explain` provides a natural-language interpretation of the CVSS vector (attack conditions, privileges, user interaction, impact breakdown). Example: For `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`, the explanation may read: "The vulnerability can be exploited remotely over the network with low complexity, without authentication and without user interaction. Exploitation may lead to high impact on confidentiality, high impact on integrity, and high impact on availability." ## When to use this tool Use this tool when the user asks: - "What is the CVSS/EPSS of this CVE?" - "Explain the CVSS vector of this vulnerability." - "What is the severity and why?" - "Give me the risk profile for this CVE." For EPSS historical trends, use `epss_timeseries`. ## Inputs Send one of these: - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - cve_ids: list of up to 100 CVE identifiers. ## Outputs With `cve_ids`: - `results`: one item for each CVE found, with `cve_id` and the fields below except `cvss_explain` - `not_found`: the CVEs that SecDB does not know With `cve_id`: - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain` - human-readable explanation of the CVSS vector - `epss_score` - as a percentage (`94.36` means 94.36%) Any of these fields is `null` when SecDB has no such data for the CVE (for example a CVE not yet analyzed or scored). ## LLM usage guidelines - Never guess CVSS or EPSS values—always call this tool. - If a field is `null`, say that the value is not available. - Use the `cvss_explain` field directly when the user wants an interpretation of the vector string. - If multiple CVEs are re	Get CVSS and current EPSS score for one CVE, or for a list of CVEs in a single call. ## What this tool does Returns a full risk snapshot for a CVE, including: - CVSS version - CVSS base score - CVSS severity - CVSS vector string - human-readable explanation of the CVSS vector - current EPSS score The field `cvss_explain` provides a natural-language interpretation of the CVSS vector (attack conditions, privileges, user interaction, impact breakdown). Example: For `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`, the explanation may read: "The vulnerability can be exploited remotely over the network with low complexity, without authentication and without user interaction. Exploitation may lead to high impact on confidentiality, high impact on integrity, and high impact on availability." ## When to use this tool Use this tool when the user asks: - "What is the CVSS/EPSS of this CVE?" - "Explain the CVSS vector of this vulnerability." - "What is the severity and why?" - "Give me the risk profile for this CVE." For EPSS historical trends, use `epss_timeseries`. ## Inputs Send one of these: - cve_id: valid CVE identifier (`CVE-YYYY-NNNNN`). - cve_ids: list of up to 100 CVE identifiers. ## Outputs With `cve_ids`: - `results`: one item for each CVE found, with `cve_id` and the fields below except `cvss_explain` - `not_found`: the CVEs that SecDB does not know With `cve_id`: - `cvss_version` - `cvss_base_score` - `cvss_base_severity` - `cvss_vector_string` - `cvss_explain` - human-readable explanation of the CVSS vector - `epss_score` - as a percentage (`94.36` means 94.36%) Any of these fields is `null` when SecDB has no such data for the CVE (for example a CVE not yet analyzed or scored). ## LLM usage guidelines - Never guess CVSS or EPSS values—always call this tool. - If a field is `null`, say that the value is not available. - Use the `cvss_explain` field directly when the user wants an interpretation of the vector string. - If multiple CVEs are re	No	Yes	Yes	No
`vulnerability_search`Perform a full-text vulnerability search in SecDB. ## What this tool does Searches across: - CVE entries - Security advisories - Exploit references - Product and vendor vulnerability data ## Searchable fields (Lucene syntax supported): - type: result type - cve, cwe, attack (ATT&CK techniques), advisory, nasl, exploitdb - id: exact identifier, without wildcards (e.g. id:CVE-2021-44228) - title: resource title or name - summary: short summary - description: full description text - alias: known vulnerability names (e.g. alias:log4shell) - severity: critical, high, medium, low - kev: true/false — CISA KEV catalog membership - status: NVD status (CVE only) e.g. analyzed, modified - published: publication date (e.g. published:>="2026-01-01T00:00:00Z") - modified: last modification date (e.g. modified:>="2026-01-01T00:00:00Z") - cve: related CVE ID (e.g. cve:CVE-2026-44827) - cwe: related CWE ID (e.g. cwe:CWE-79) - tag: advisory tag, or ATT&CK tactic of a technique (e.g. tag:persistence) - attack_vector: network, adjacent, local, physical - cvss_score: CVSS base score (e.g. cvss_score:>=7) Default operator is AND. Use OR for alternatives, quotes for exact phrases, * for wildcards. For ranges use `>`, `>=`, `<`, and `<=`, repeating the field for both ends. Dates need a quoted date and time in UTC. ## Examples: - "apache struts rce" → RCE vulnerabilities in Apache Struts - "id:CVE-2026-44827" → exact CVE lookup - "type:advisory AND severity:critical" → critical advisories - "alias:log4shell" → Log4Shell by alias - "cve:CVE-2026-44827 AND type:exploitdb" → ExploitDB entries for a CVE - "cvss_score:>=9 AND kev:true" → critical KEV CVEs - "type:attack AND tag:credential-access" → ATT&CK techniques of the Credential Access tactic - "type:cve AND published:>=\"2026-10-01T00:00:00Z\" AND published:<=\"2026-10-31T23:59:59Z\"" → CVEs published in October 2026 ## When to use this tool Use this tool when the user asks: - to look up a CVE, advisory, exploit, or product - "show v	Perform a full-text vulnerability search in SecDB. ## What this tool does Searches across: - CVE entries - Security advisories - Exploit references - Product and vendor vulnerability data ## Searchable fields (Lucene syntax supported): - type: result type - cve, cwe, attack (ATT&CK techniques), advisory, nasl, exploitdb - id: exact identifier, without wildcards (e.g. id:CVE-2021-44228) - title: resource title or name - summary: short summary - description: full description text - alias: known vulnerability names (e.g. alias:log4shell) - severity: critical, high, medium, low - kev: true/false — CISA KEV catalog membership - status: NVD status (CVE only) e.g. analyzed, modified - published: publication date (e.g. published:>="2026-01-01T00:00:00Z") - modified: last modification date (e.g. modified:>="2026-01-01T00:00:00Z") - cve: related CVE ID (e.g. cve:CVE-2026-44827) - cwe: related CWE ID (e.g. cwe:CWE-79) - tag: advisory tag, or ATT&CK tactic of a technique (e.g. tag:persistence) - attack_vector: network, adjacent, local, physical - cvss_score: CVSS base score (e.g. cvss_score:>=7) Default operator is AND. Use OR for alternatives, quotes for exact phrases, * for wildcards. For ranges use `>`, `>=`, `<`, and `<=`, repeating the field for both ends. Dates need a quoted date and time in UTC. ## Examples: - "apache struts rce" → RCE vulnerabilities in Apache Struts - "id:CVE-2026-44827" → exact CVE lookup - "type:advisory AND severity:critical" → critical advisories - "alias:log4shell" → Log4Shell by alias - "cve:CVE-2026-44827 AND type:exploitdb" → ExploitDB entries for a CVE - "cvss_score:>=9 AND kev:true" → critical KEV CVEs - "type:attack AND tag:credential-access" → ATT&CK techniques of the Credential Access tactic - "type:cve AND published:>=\"2026-10-01T00:00:00Z\" AND published:<=\"2026-10-31T23:59:59Z\"" → CVEs published in October 2026 ## When to use this tool Use this tool when the user asks: - to look up a CVE, advisory, exploit, or product - "show v	No	Yes	Yes	No

Details

Registry status: Active
Published: Jul 2, 2026
Updated: Jul 2, 2026
Website: https://secdb.nttzen.cloud/docs/integrations/mcp⁠ (opens in a new tab)
Repository: Not given
Categories (suggested): SecuritySuggested categories are assigned automatically from the registry text and may be wrong. Verified operators can correct them.
GDPR: Not declared

Are you the operator? Claim this listing