文章总结： AutoCVE是开源CVE候选挖掘平台，通过多Agent编排实现项目筛选、扫描、源码深挖到沙箱验证的流水线。核心FindingAgent采用ReAct循环与Finalizer机制确保结构化证据收集，实测一周产出30个候选漏洞。建议务必人工复核LLM结论与PoC可复现性，修改默认凭据，并在授权范围内遵循负责任披露流程。 综合评分： 90 文章分类： 代码审计,漏洞分析,安全工具,AI安全,产品介绍

AutoCVE：自动化挖掘 CVE

攻防录

2026年7月18日 06:00 北京

在小说阅读器读本章

去阅读

简介

AutoCVE 是一套面向源码审计和 CVE 候选挖掘的开源平台。它把 GitHub 项目筛选、仓库导入、Agent 审计、沙箱验证、漏洞管理和报告生成串成了一条流水线。

项目地址：

https://github.com/larlarua/AutoCVE

它不是“点一下就自动拿到 CVE 编号”。更准确地说，AutoCVE 负责发现候选漏洞、收集证据和整理报告，研究员负责复核结论并完成负责任披露。

AutoCVE 架构总览

技术原理

一条可追踪的审计流水线

AutoCVE 的前端使用 React 和 Vite，后端使用 FastAPI。PostgreSQL 保存项目、任务、漏洞和审计会话，Redis 处理运行状态与后台任务，PoC 和安全工具则放进 Docker 沙箱执行。

审计主流程由 Orchestrator 编排：

Orchestrator
  └─ Recon
      ├─ Scan → Triage ─┐
      └─ Finding ───────┼─ Verification → Merge / Finalize

各 Agent 之间传递的是结构化结果，而不是一大段散乱文本。任务阶段、工具调用、交接记录、检查点和最终发现都会写入会话，前端再通过 SSE 实时展示。

| Agent | 负责的工作 | 主要产物 | | — | — | — | | Orchestrator | 选择并调度工作流 | 执行顺序、合并结果 | | Recon | 识别语言、框架和攻击面 | 优先审计路径 | | Scan | 调用 Semgrep、Bandit、Gitleaks 等工具 | 静态扫描候选 | | Triage | 复核扫描结果、过滤误报 | 可信候选与补充证据 | | Finding | 直接阅读源码并追踪数据流 | 结构化漏洞发现 | | Verification | 在沙箱中运行测试或 PoC | 验证状态与证据 |

三种审计模式

AutoCVE 没把所有项目都塞进同一条重型流程，而是提供三种模式：

| 模式 | 执行链路 | 更适合的任务 | | — | — | — | | 增强扫描 | Scan → Triage | 快速处理工具扫描结果 | | 智能审计 | Finding | 深入追踪业务逻辑和高价值漏洞 | | 综合审计 | Scan → Triage + Finding | 工具覆盖与源码深挖同时进行 |

增强扫描速度更快，但效果受规则覆盖率影响。智能审计更依赖模型能力和上下文成本。综合审计覆盖更完整，耗时和 Token 消耗也更高。

Finding Agent 的 ReAct 循环

Finding Agent 是这套系统的重点。它不会只让模型读取一次代码后直接生成结论，而是把审计拆成多轮循环：读取会话状态、合并项目上下文、调用模型、执行工具、保存结果，再判断继续还是结束。

Finding Agent 的 ReAct 循环

每一轮中，模型可以调用 Read、Glob、Grep、Bash、PowerShell 和 Skill 等工具。只读且可并发的操作可以并行执行；写文件、Shell 和沙箱类操作通常串行执行，并经过输入校验、权限检查和审计记录。

模型声称“分析完成”并不算真正结束。Finding Agent 必须调用 FinalizeFinding，提交漏洞类型、文件位置、Source、Sink、利用链、PoC、影响、CVE 依据和验证说明等字段。

字段不全时，Finalizer 会拒绝结束并把缺项返回给模型。模型只说“继续分析”却没有调用工具时，Nudge 机制也会提醒它执行下一步。这样能减少两类常见问题：证据没补齐就收工，以及输出一段看似完整但无法落库的自然语言报告。

一键 CVE”实际做了什么

一键 CVE”本质上是一个批次调度器。用户输入 1—10 个目标漏洞数量后，系统会筛选 GitHub 候选项目，持续导入并创建审计任务，直到达到目标数量或候选耗尽。

筛选时会参考项目活跃度、是否归档、Release 或 Tag、SECURITY.md、Security Advisory 和 Private Vulnerability Reporting 等信号。源码中的默认策略会准备不少于 8 个候选，或按目标数量的 3 倍扩充候选池。

这套机制自动化的是重复劳动。报告不会自动提交给维护者，也不会保证每个候选都能获得 CVE 编号。

仓库公布的实战结果

项目 README 称，AutoCVE 在一周测试中发现并提交了 30 个漏洞，覆盖 14 个开源项目，列表最高 CVSS 为 9.9。完整报告放在：

https://github.com/larlarua/vulnerability-reports

这组数据更适合作为项目方的阶段性测试记录，不是可复现的统一基准。按 2026 年 7 月 17 日查询 CVE Program 官方 API，README 列出的 30 个编号中有 25 个处于 PUBLISHED 状态，另外 5 个当时未查到公开记录；个别评分也已与 README 不同。

其中，CVE-2026-43986 的官方记录为已发布，CVSS 3.1 评分 9.9：

https://www.cve.org/CVERecord?id=CVE-2026-43986

漏洞状态和评分可能继续更新，提交报告前最好重新核对官方记录。

快速上手

1. 准备运行环境

官方文档建议至少准备 4 核 CPU、8 GB 内存和 20 GB 磁盘，并安装 Docker 20.10+ 与 Docker Compose 2.24.0+。小项目可以在 4 GB 内存下运行，大仓库和综合审计更吃资源。

Linux、macOS 或 Git Bash 可以直接使用固定版本的 Compose 文件：

curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml \
  | docker compose -f - up -d

如果准备长期使用，建议先下载并检查 Compose 文件，再启动服务。做二次开发则直接克隆源码：

git clone https://github.com/larlarua/AutoCVE.git
cd AutoCVE
docker compose up -d --build

2. 检查服务

docker compose ps

默认服务地址如下：

| 服务 | 地址 | | — | — | | 前端 | http://localhost:3000 | | 后端 API | http://localhost:8000 | | Swagger | http://localhost:8000/docs | | Adminer | http://localhost:8080 |

初始演示账号为 [email protected] / demo123。首次登录后先修改或删除默认账号，生产环境不要保留这组凭据。

3. 配置模型

进入“系统设置 → 模型配置”，填写 Provider、模型名称、API Key 和 Base URL，再执行连接测试。

模型配置

AutoCVE 支持给不同 Agent 单独分配模型。例如 Recon 使用速度较快的模型，Finding 和 Verification 使用推理能力更强的模型。中转站的协议与工具消息格式必须匹配，否则普通对话可能正常，工具调用却会失败。

4. 导入项目并创建审计

项目可以通过 GitHub、GitLab、Gitea 仓库地址导入，也可以上传 ZIP。私有仓库需要配置对应 Token 或 SSH 私钥。

创建任务时填写版本号，选择审计模式，并决定是否开启动态验证。动态验证会增加运行时间，也会执行更多沙箱操作，建议先在小型测试项目中熟悉流程。

启动审计任务

5. 人工复核报告

审计结束后，漏洞会进入漏洞管理。报告页提供中文报告、English Report 和 CVE 报告，可以编辑、复制或导出 Markdown。

漏洞报告示例

重点检查文件路径、受影响版本、Source 到 Sink 的完整链路、PoC 可复现性和修复建议。Agent 给出的 CVSS、CWE 和影响范围也需要人工复算。

使用场景

1. 开源项目 CVE 候选研究

任务示例： 从近期活跃、具备安全响应入口的 GitHub 项目中筛选目标，批量创建源码审计任务。

技术要点： 使用“一键 CVE”减少找项目和建任务的重复操作，但不要按候选数量等同于有效漏洞数量。每条发现都要复现，并按项目的 SECURITY.md 或 Private Vulnerability Reporting 流程披露。

2. 单仓库深度代码审计

任务示例： 对一个 Web 项目的鉴权、文件处理、URL 请求和命令执行路径做专项审计。

技术要点： 选择智能审计或综合审计，为 Finding Agent 绑定语言、框架或漏洞类型对应的 Skill。通过后续会话要求 Agent 补查调用链，别只看首轮报告。

3. 安全团队内部复核

任务示例： 将 Semgrep、Bandit、依赖扫描和密钥扫描的候选结果交给 Triage，再由 Verification 在隔离环境中验证。

技术要点： 保留活动日志、工具调用和 Agent Handoff，方便复盘误报来自哪一阶段。对高风险 PoC 设置更严格的沙箱权限，不要把宿主机当验证环境。

4. Agent 安全工程研究

任务示例： 分析长任务中模型为什么提前结束、工具调用为何失败，以及上下文压缩后是否丢失证据。

技术要点： AutoCVE 已把 Continue、Terminal、Nudge、Checkpoint、Memory 和 Finalizer 拆成独立运行时组件，适合研究 Agent 如何从“能对话”走向“可审计、可恢复、可约束”。

需要注意的点

• LLM 结果不是漏洞结论。误报、受影响版本偏差和 PoC 不可复现都需要人工处理。
• 综合审计和动态验证会消耗较多 Token、CPU、内存与时间，先用小项目估算成本。
• 默认演示账号必须更换，模型密钥和私有仓库 Token 也要按生产凭据管理。
• 只在明确授权的项目和环境中执行扫描与验证，并遵循维护者的披露流程。
• 项目采用 AGPL-3.0，二次开发和对外提供服务前应确认许可证义务。

结尾

AutoCVE 的价值不在“一键拿编号”，而在于把 CVE 研究中最耗时间的工程步骤连起来：筛选项目、调度审计、保存证据、验证漏洞、管理结果和草拟报告。

如果你更关心的是 Agent 如何稳定完成一项长时间代码审计任务，AutoCVE 的 ReAct Runtime、Nudge、Finalizer 和审计追踪，同样值得拆开研究。

项目文档：

https://github.com/larlarua/AutoCVE/blob/main/docs/USER_GUIDE.md

架构文档：

https://github.com/larlarua/AutoCVE/blob/main/docs/ARCHITECTURE_DESIGN.md

往期推荐 📚

Tutti：让多个 Agent 共用一个工作台

AntiDebug MCP：AI 前端逆向助手

Shannon：白盒 AI 渗透测试

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：攻防录 《AutoCVE：自动化挖掘 CVE》