vuln-intel

vuln-intel

大多数 CVE 工具都把原始数据交给你的 Agent。这个工具会根据实际遭受攻击的情况进行排序，按漏洞机制查找漏洞，识破 Agent 编造的 CVE，还能从约 14,000 份已公开的漏洞赏金报告中迁移攻击机制。

一个经过整理、托管的 MCP 语料库：约 364,000 个 CVE，整合了 NVD + CISA KEV + FIRST EPSS + OSV/GHSA + CISA Vulnrichment (SSVC)，另有从 约 14,000 份已公开并获得赏金的漏洞报告中提炼出的机制层——每日更新。它不是又一个实时 API 封装器。

免费。 获取密钥：输入你的邮箱，我们会发送你的专属密钥。告诉我你在排查什么。

---

为什么选它，而不是下一个 CVE 封装器

大多数 CVE MCP 服务都是轻量封装器：查询时，它们会同时调用相同的免费公共 API，然后把返回结果原样交给你。它有五个具体的不同之处。

• 经过整理的内嵌语料库，而不是实时代理。 每个漏洞对应一条记录，通过身份图谱整合 NVD、OSV/GHSA 和 KEV 数据，并包含约 2,100 个经过供应商限定的产品别名以及用于语义搜索的嵌入向量。在本地查询，排序一致。
• 以 SSVC 而非仅 CVSS 作为优先级依据。 优先级以可利用性为先：CISA SSVC（活跃利用 / 可自动化 / 总体影响）、KEV 和 EPSS 共同决定 P1 到 P4 的排名。那些封装型 MCP 完全不包含 SSVC。
• 按机制搜索，而不是按关键词搜索。 语义搜索可以在不同产品中找到相同的漏洞类别。关键词工具在结构上就做不到。
• 它会核验 Agent 的说法。 verify_cve_claim 能发现编造的 CVE 和错误属性。眼下这一点最重要，因为 AI 编造的漏洞报告正大量涌入分诊流程，而几乎没有其他 CVE MCP 能做到这一点。
• 供应商识别准确，不会误报为零。 “GitHub Enterprise”会匹配到正确的供应商，而不是所有名称中包含“enterprise_server”的产品。无法识别的产品会返回 resolved: false 和建议，而不是悄无声息地返回 0，让人以为“没有影响”。错误的零结果是安全工具可能给出的最糟糕答案。

AI 辅助安全的难点不在于发现 CVE，而在于分诊、确定优先级和减少误报。这正是本工具要解决的问题。

以下内容均为实时服务的真实输出，仅为控制篇幅进行了删减。

---

它会核验 Agent 的说法

最重要的差异化功能。你的 Agent 引用了 CVE-2025-99999：

verify_cve_claim("CVE-2025-99999")
  ->  exists: false    "No record in NVD / OSV / GHSA. Likely hallucinated or not-yet-published."

或者它给出的详情有误。它声称：“CVE-2021-44228 是一个中危 Apache Struts 漏洞，而且没有遭到利用。”

verify_cve_claim("CVE-2021-44228", product="Apache Struts", severity="medium", exploited=false)
  refuted  "not exploited"          ->  in CISA KEV (added 2021-12-10)
  refuted  "severity medium"        ->  actual CVSS 10.0, P1
  refuted  "affects Apache Struts"  ->  no product matching "Apache Struts"

其他数据源只是把数据交给你的 Agent。这个工具会在内容进入报告前，告诉你 Agent 是否出错。

优先级以可利用性为先（SSVC、KEV、EPSS），而非 CVSS

check_technology("GitLab") 会返回该产品的 792 个 CVE，去重并排序，让遭到利用的漏洞排在前面：

P1  KEV  EPSS 99.8   CVE-2023-7028   account-takeover: password-reset email sent to an attacker address (CVSS 10)
P2  KEV  EPSS 98.5   CVE-2021-39935  unauthenticated SSRF via the CI Lint API
P3       EPSS 99.7   CVE-2023-2825   unauthenticated path traversal, arbitrary file read (CVSS 10)
P3       EPSS 99.7   CVE-2022-2992   authenticated RCE via the GitHub import API (CVSS 9.9)

映射到多个供应商的名称会标记为 ambiguous（此处是 gitlab 与一个 jenkins 插件），并分别保留，绝不会悄悄合并。随后，enrich_cve 会为其中任意一个 CVE 提供完整的 SSVC 信息：

enrich_cve("CVE-2024-3400")   PAN-OS GlobalProtect
  P1  KEV  CVSS 10.0  EPSS 99.95    unauthenticated command injection -> root RCE
  SSVC          exploitation=active   automatable=yes   technical_impact=total
  Metasploit    exploit/linux/http/panos_telemetry_cmd_exec  (rank: excellent)
  Public PoC    44 repos   (h4x0r-dz 162 stars, W01fh4cker 90 stars, ...)

将侦察结果转化为排查顺序

hunt_plan(["craftcms 4.4", "nginx", "keycloak"]) 会根据技术栈中最容易遭到利用的漏洞进行排序，并指出各个组件历来容易出现问题的地方：

#1  craftcms 4.4    97 CVEs, 12 high-risk
    recurring_loci   CWE-94 code injection x7 (2 exploited in the wild)  ->  probe template / eval surfaces first
    dig here
       P1 KEV EPSS 99.8   CVE-2025-32432   unauthenticated RCE (CVSS 10)        your 4.4 is AFFECTED, fixed in 4.14.15
       P1 KEV EPSS 99.9   CVE-2024-56145   RCE when register_argc_argv is on    AFFECTED, fixed in 4.13.2

#2  nginx           HTTP/2 Rapid Reset CVE-2023-44487 (KEV)
#3  keycloak        recurring_loci CWE-287 auth x12.  OIDC request_uri SSRF CVE-2020-10770

它不只是列出 CVE，还会指出某个产品系列反复出现的漏洞类别，根据实际利用情况排序，并告知你的版本是否受到影响。告诉你该去哪里查，以及应该预期看到什么。

跨产品按机制搜索

find_similar_vulns(cve_id="CVE-2021-44228")，“还有什么漏洞的原理和 Log4Shell 一样”：

sim 0.88   CVE-2021-44832   Log4j2 JDBC Appender, JNDI LDAP RCE
sim 0.82   CVE-2022-40145   Apache Karaf, code injection via an attacker-controlled JNDI URL
sim 0.79   CVE-2022-34916   Apache Flume, JNDI LDAP RCE via a JMS source

同一种 JNDI 注入机制，出现在不同产品中。搜索关键词“log4j”永远找不到 Karaf 或 Flume。也可以直接搜索一个概念：search_vulns("SAML SSO authentication bypass")：

P3      CVSS 9.1  CVE-2024-9487   GitHub Enterprise: SAML SSO bypass via signature verification
P3      CVSS 9.8  CVE-2025-25291  ruby-saml: auth bypass via a ReXML / Nokogiri parser differential
P1 KEV  CVSS 9.8  CVE-2025-59718  Fortinet FortiOS / FortiProxy: signature-verification bypass

查看当前正在被利用的漏洞

find_recent_high_risk(days=7)，今天实时运行：

P1 KEV CVSS 10.0  CVE-2026-10520  Ivanti Sentry: unauthenticated OS command injection -> root RCE
P1 KEV CVSS 9.3   CVE-2026-50751  Check Point: IKEv1 auth bypass, remote-access VPN without a password
P2 KEV CVSS 8.8   CVE-2026-11645  Chrome V8: out-of-bounds read/write -> sandbox escape RCE

从漏洞披露到在野利用的中位时间如今以天计，而非月。上面的 Ivanti 漏洞公布当周就有 CISA 修复期限。当前的 corpus_stats：约 364,800 个 CVE、约 1,630 条 KEV 条目，数据不到一天——这些数字是某一时点的数据，每天都在变化，因此请自行调用 corpus_stats 查询实时数量，而不是相信本页面上的数字。

从已披露的漏洞赏金报告中迁移攻击机制

除 CVE 外，语料库还将约 14,000 份已披露且获得奖金的 HackerOne 报告提炼为与产品无关的攻击机制——每个漏洞都包含 source → sink → trigger → preconditions，并剥离其提交所针对的产品信息。其前提是：漏洞是一种可迁移的机制，而非某个产品的特性——因此，在一个技术栈上奏效的招式，就是下一个技术栈上的检查清单。

find_attack_approaches(query="ssrf reaching cloud metadata")——已迁移的人工操作，按新颖性排序，每项都标记了当前项目的可操作性：

Reddit         SSRF   preview_url fetches an unfiltered URL → returns metadata    program_active, pays
U.S. DoD       SSRF   /download-url?url= fetches AWS instance metadata            program_active
Concrete CMS   SSRF   DNS-rebind bypass → AWS IAM creds from the metadata svc     program_active

• find_continuations(position=...)——将你累积的攻击者位置与真实报告在类似位置采取的后续招式进行匹配。每个招式的 status 都是 UNVERIFIED，并附有要在目标上执行的 decisive_check——这是合法招式，绝非已确认的漏洞。
• assist_submission(finding=...)——根据最接近的已付费先例生成有依据的提交摘要（有效性、新颖之处、升级操作手册），并根据语料库验证每份引用报告（citations_grounded），确保不会混入伪造的先例。
• program_outcome_prior("hackerone:gitlab")——某个项目历史上确实收到过的漏洞类型，以及它们相对于基准率的提升幅度（GitLab：SSRF 为 3.4×，SQLi 几乎从未出现）。

坦诚地说，这是什么：它为人工猎手提供预备信息和依据——呈现招式和先例。它不会替你找到漏洞；招式能否奏效取决于目标，而这一步仍需你亲自执行。

---

核心所在：借鉴并执行的机制记忆，而非 CVE 查询

护城河是无状态模型无法自行生成的三样东西，而这个语料库全都具备：

• 长期观察——先验数据、时间变化（Log4Shell 的受影响范围在发布 1,200 多天后仍在扩大）、评分稳定性。你的模型只有训练截止时的快照；这里有的是变化轨迹。
• 见过许多案例——所有已披露的机制和 CVE 机制都经过向量化，因此同一类漏洞可以迁移到模型永远不会关联起来的产品上：Log4Shell 的 JNDI 查找机制 → Apache Karaf、Flume；在 Reddit 上获得奖金的 SSRF → 可在下一个目标上尝试的招式。
• 实时融合侦察——observe 从主机的 JS 包中还原其真实后端，并当场将其与语料库关联。

最忌讳的就是把它当作严重性分数检查器。它的任务是将已验证的机制迁移到你的目标上并执行——或者通过阅读修复方案来证伪某个选项，避免在它上面浪费一次探测。

强制你的 Agent 使用它——它不会自行使用

如果不加干预，Agent 会根据训练数据作答：信息过时，而且在压力下会编造 CVE ID。将以下操作循环粘贴到 Agent 的规则中（CLAUDE.md、Cursor/Windsurf 或系统提示词）：

You have the vuln-intel MCP. Your own CVE knowledge is a guess to be verified — prefer the corpus.
Operating loop, in order:
1. Scoping a bounty program → program_outcome_prior (which bug classes have actually PAID here).
2. A live host → observe (call twice; the 2nd returns the cache). Mine endpoints[], recurring_loci, the CVE join — not two fields.
3. A product + version → check_technology / hunt_plan (dig-order + the recurring CWE loci).
4. Before asserting ANY CVE / "affects X" / "severity Y" / "exploited" → verify_cve_claim. Never cite from memory.
5. Feasibility of one CVE → enrich_cve; read the MECHANISM (POST vs GET, auth-required) to judge whether it chains.
6. Hunting a class → find_attack_approaches for the transferable move; RUN it on the target, don't cite it. Loop with a growing tried=.
7. Stuck / messy position → find_continuations(position) for the by-step move; then search_vulns that class against the target to prove it's live here.
8. Submitting → assist_submission; EXECUTE the techniques it transfers (referrer differential, key-reuse breadth), then file.
Above all: a finding isn't a finding until a cheap check that would kill it has failed to.

它会呈现行动思路和先例；最终由目标决定哪些经得起验证。 最后一条规则体现了产品的核心理念——每个工具都自带一项否定性检查（verify_cve_claim 的反驳结果、UNVERIFIED + decisive_check、ambiguous、citations_grounded），因此 Agent 绝不会把有限的信号误读为绿灯。

---

免费连接

claude mcp add --transport http vuln-intel https://mcp.rozetyp.com/mcp \
  --header "Authorization: Bearer <YOUR_KEY>"

或者使用任意 MCP 客户端（mcp.json）：

{
  "mcpServers": {
    "vuln-intel": {
      "type": "http",
      "url": "https://mcp.rozetyp.com/mcp",
      "headers": { "Authorization": "Bearer <YOUR_KEY>" }
    }
  }
}

你只需要一个免费密钥。请见下文的获取密钥。

十三个工具

CVE 情报：

工具	输入	返回内容
check_technology	产品（+ 版本、供应商）	按优先级排列的 CVE，已合并 NVD CPE + OSV 中的重复项，并标记歧义
hunt_plan	已侦察的技术栈	各组件的检查顺序 + 反复出现的漏洞类别（CWE）位置
enrich_cve	CVE ID	完整档案：CVSS、KEV、EPSS、SSVC、受影响范围、Metasploit + 实时 PoC 仓库
verify_cve_claim	CVE + 声称的属性	各项声明的 supported / refuted / unverifiable 状态 + 证据
find_recent_high_risk	时间范围（+ 产品）	新近变得危险的 KEV / 高 EPSS CVE
find_similar_vulns	概念或种子 CVE	跨产品的机制相似漏洞，并附余弦相似度
search_vulns	自由文本（+ CWE）	按相关度排列的全文匹配 + 总覆盖范围
search_public_code	精确代码字符串	出现该字符串的公开仓库（仓库 / 文件 / URL）
corpus_stats	—	语料库规模和数据新鲜度

漏洞赏金机制迁移（基于约 1.4 万份已披露报告）：

工具	输入	返回内容
find_attack_approaches	目标 / CVE / 漏洞类别	可迁移的攻击机制，按新颖度排序 + 实时项目可操作性
find_continuations	你在狩猎过程中的当前攻击者位置	真实报告从该位置采取的后续行动，每项均标记为 UNVERIFIED + 一项决定性检查
assist_submission	漏洞发现草稿	有依据的提交摘要 + 升级处理方案，带引用核验（citations_grounded）
program_outcome_prior	漏洞赏金项目	历史上在该项目中成功的漏洞类别 + 相较于基准率的提升

它会列出事实、按优先级排序的上下文和可迁移的先例——绝不提供漏洞利用或载荷。由你的 Agent 进行推理；最终由目标决定哪些经得起验证。

完整参考文档——包含每个工具的全部参数、响应字段和一个实时示例——见 TOOLS.md。

使用它进行漏洞狩猎：技能 + 操作手册

两份采用 MIT 许可证的配套文档将语料库转化为实际发现，而不只是 CVE 查询：自包含的 Claude 漏洞赏金狩猎技能（将文件夹放入 ~/.claude/skills/，之后它会在收到“hunt for bugs” / “is this exploitable”指令时加载），以及按需深入使用的**MCP 操作手册**（各工具的注意事项、构思循环、验证模式）。两者均可独立使用：请见 bug-bounty-hunting/。

它不是什么

它不是扫描器，不是漏洞利用工具，也不能替代 SBOM / SCA。它是 AI 辅助安全工作中的事实依据、优先级排序和事实核查层。

获取密钥

免费。 前往 vulntel.com/signup，输入你的电子邮箱，系统会将个人密钥发送给你。想直接咨询？请发送邮件至 [email protected]，并说明你正在进行的工作（漏洞赏金、渗透测试、研究）。密钥按用户分配，可追溯且可撤销。

---

仅用于经授权的防御性安全研究和漏洞赏金分诊。不得用于漏洞利用。输出仅供决策参考，不能替代你自己的验证。

© 2026 rozetyp。保留所有权利。本项目不开源；请见 LICENSE。