VulnHunter:AI 驱动的自动化漏洞发现 Agent 平台
AI 驱动的自动化漏洞发现 Agent 平台
VulnHunter 是一个开源的 AI 漏洞挖掘工作台,集成了自动化目标分析、AI 辅助漏洞发现、对话式调查、POC/EXP 生成验证、审核工作流和报告交付,支持自部署运行。
📸 界面预览
🎛️ Dashboard 总览
🔍 漏洞发现
🤖 AI Chat 助手
💥 POC/EXP 验证
📊 审计报告
⚡ 为什么选择 VulnHunter?
| 😫 传统方式 | 💡 VulnHunter 方案 |
|---|---|
| 人工代码审计效率低 — 跟不上代码迭代速度 | 🤖 AI Agent 自动审计 — YoungFlow 编排多 Agent 协作,全自动执行 |
| 工具误报多 — 传统 SAST 缺乏语义理解 | 🧠 上下文感知 — AI 结合代码语义和业务逻辑,精准定位真实漏洞 |
| 漏洞无法确认 — 不知道是否真实可利用 | 💥 自动 POC 验证 — 自动生成并执行 POC,确认漏洞有效性 |
| 审计结果散落 — 报告、POC、沟通分散在多个工具 | 🏠 统一工作台 — 扫描、Chat、POC、报告、审核全部在一个平台 |
| 学习成本高 — 需要熟悉多种安全工具 | 💬 对话式操作 — 自然语言交互,通过 Chat 完成大部分操作 |
🎯 功能矩阵
| 功能 | 说明 |
|---|---|
| 🔍 AI 漏洞发现 | 基于 YoungFlow Agent 编排,自动分析目标项目并发现潜在漏洞 |
| 💬 Chat AI 助手 | 内置 16+ MCP 工具,通过对话查询漏洞、操作任务、切换模型 |
| 💥 POC/EXP 生成 | AI 自动生成 POC 脚本,DeVeye 浏览器自动化验证 |
| 📊 审计报告 | YoungFlow 编排生成专业 Markdown 报告 |
| ✅ 漏洞审核 | 逐条/批量审核工作流,4 状态管理 |
| 📋 任务管理 | 全生命周期管理:创建、暂停、取消、恢复、重跑 |
| 🎛️ Dashboard | 实时统计、严重度分布、审核进度追踪 |
| 🔐 凭证管理 | 多模型凭证配置、运行时切换、可用性诊断 |
| 🐳 容器化部署 | Docker Compose 一键部署,Worker 容器隔离执行 |
版本对比
| 功能 | Community(开源) | Enterprise(商业) |
|---|---|---|
| 上述所有功能 | ✅ | ✅ |
| 单用户管理 | ✅ | ✅ |
| 多用户 RBAC | ❌ | ✅ |
| License 授权 | 免费,无需激活 | ✅ |
| 技术支持 | 社区 | 专属 |
🏗️ 系统架构
┌─────────────────────────────────────────────────────┐
│ 浏览器 (React/Vite) │
└──────────────────────┬──────────────────────────────┘
│
┌──────────────────────▼──────────────────────────────┐
│ VulnHunter Service (Hono + WebSocket + MCP) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ Tasks │ │ Chat │ │ Reports/POC │ │
│ │ Findings │ │ AI Agent │ │ Review Workflow │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
└───┬────────────────┬────────────────┬───────────────┘
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────────┐ ┌───────────────────┐
│PostgreSQL│ │ MinIO │ │ Docker Workers │
│ 任务/漏洞 │ │ 文件/报告 │ │ ┌───────────────┐ │
│ 用户/配置 │ │ 源码/产物 │ │ │ YoungFlow Scan│ │
└────────┘ └────────────┘ │ │ Chat Worker │ │
│ │ Report Worker │ │
│ │ POC/Eval │ │
│ └───────────────┘ │
└───────────────────┘
核心组件:
packages/
├── shared/ 共享 API 类型
├── service/ 核心后端服务
├── web/ React 前端
├── worker-bridge/ Worker 侧桥接通信
└── enterprise/ 商业增值功能(BSL 1.1)
🚀 快速开始
环境要求
- x86_64 Linux 主机(推荐 Ubuntu 22.04+)
- Docker Engine + Docker Compose v2
- 从源码构建需 Git、Node.js 20+ 和 pnpm 9+
- 平台运行至少 16GB 内存(构建镜像可能需要更多)
从源码构建并安装(社区版)
VulnHunter 的应用镜像未发布到公共仓库。应先从源码构建包含镜像的离线发布包;仅克隆仓库后直接运行 docker compose up 无法完成安装。
git clone --recurse-submodules https://github.com/Clouditera/VulnHunter.git
cd VulnHunter
pnpm install --frozen-lockfile
./scripts/build-release.sh --edition community
VERSION=$(node -p "require('./package.json').version")
cd "release/vulnhunter-release-${VERSION}-community"
./install.sh
./doctor.sh
访问 http://localhost:23000,首次启动在引导页设置管理员账号即可使用。如果已有包含 images/*.tar 的离线发布包,解压后在发布包目录运行 ./install.sh 和 ./doctor.sh 即可,无需从源码构建。
源码开发
# 安装依赖
pnpm install
# 构建
pnpm build
# 运行测试
pnpm test
# 启动基础设施(数据库 + 对象存储)
docker compose -f deploy/docker-compose.yml --env-file deploy/.env.example up -d db minio
⚙️ 配置说明
参考 deploy/.env.example,常用配置项:
| 变量 | 说明 | 默认值 |
|---|---|---|
WEB_PORT |
Web 端口 | 23000 |
DATA_DIR |
数据持久化目录 | /opt/vulnhunter/data |
DOCKER_SUBNET |
Docker 网络子网 | 10.177.0.0/24 |
VULNHUNTER_MASTER_KEY_FILE |
凭证加密主密钥路径 | — |
WORKER_IMAGE |
扫描 Worker 镜像 | vulnhunter-worker:latest |
EDITION |
版本模式 | community |
📜 开源协议
本项目采用 Open Core 模式:
- 社区/开源核心 — Apache License 2.0 附加条件(禁止未授权对外托管 SaaS/托管服务;界面须保留 VulnHunter 品牌标识)。
- Enterprise / SaaS — 非 BSL,无自动转开源日期。
🤝 参与贡献
欢迎贡献!当前贡献指南正在完善中,基本流程:
- 提交 Issue 描述 Bug、功能建议或文档改进
- Fork 后开发,保持改动聚焦
- 提交前确保
pnpm build && pnpm test通过 - 提交 Pull Request
请勿提交:密钥、私有扫描数据、客户数据、运行时产物。
⚠️ 安全与合法使用声明
VulnHunter 是面向安全研究与授权测试的工具。
仅可对您拥有、或已获得明确授权进行测试的系统、代码库与服务使用本软件。
禁止将本软件用于:
- 未经授权的漏洞扫描、渗透或攻击;
- 挖掘、利用漏洞从事任何违法犯罪活动;
- 对第三方系统造成破坏、窃取数据、勒索或拒绝服务等侵害。
使用本软件即表示您理解并同意:因非法或未授权使用所产生的一切后果由使用者自行承担,与项目维护方无关。







评论1次
VulnHunter 攻击方视角分析
工具定位与红队价值
VulnHunter 本质上是一个AI 编排的 SAST 增强工作台,把传统静态分析里最耗时的"语义理解 + 利用验证"两段用 LLM Agent 接管。它的攻击侧价值不在"扫描"这一步,而在于自动化产出可利用 POC——传统 SAST 输出的是告警,VulnHunter 试图直接给出"这条漏洞能不能打"。
对红队来说,这意味着:
架构层值得关注的点
从攻击方角度看这套架构有几个有意思的设计:
Worker 容器隔离(
WORKER_IMAGE+DOCKER_SUBNET=10.177.0.0/24):每个任务跑在独立容器里,攻击代码/恶意 payload 不会污染主机。从红队视角反过来想——如果你是测试这个平台的人,看 worker 容器的网络隔离强度和共享卷就能判断它的横向扩展安全性。凭证管理 + 主密钥(
VULNHUNTER_MASTER_KEY_FILE):DB 里的 LLM API key、目标xi统凭证都是加密存储的。这个 master key 文件如果泄露,等于整套xi统的所有客户凭证全部裸奔——属于高价值资产。MinIO 存源码和报告:扫描的目标源码直接落对象存储,攻击这个平台的人能拿到的不只是平台本身,还有所有客户上传过的待审计代码——信息密度极高的目标。
自动化 POC 这条路的现实瓶颈
VulnHunter 想解决的"自动生成 POC 并验证"在实战里有个根本问题:可利用 ≠ 可执行。参考铁威马 NSA 那个案例(CVE-2022-24990),完整的攻击链是:
/module/api.php?mobile/webNasIPS泄露 PWD 路径AUTHORIZATION+SIGNATURE头raidtype参数注入命令; ; |这种多步、依赖特定认证头、链式触发的场景,AI Agent 要自动串起来并不容易。如果 VulnHunter 的 POC 验证只覆盖"单步发包看响应"这一类(SQL 注入反射、SSRF 回带、未授权访问),那它对真实打点的帮助仍然有限——红队拿到这类"漏洞"还得自己手工构造利用链。
对比传统工作流的优势区间
VulnHunter 的 Chat + MCP 模式真正的甜区是:
弱势区间:
红队实战使用建议
如果要在真实渗透中引入这套工具:
10.177.0.0/24子网,避免和内网混跑一点延伸思考
从工具演进角度看,VulnHunter 这类平台的出现说明漏洞挖掘正在从"规则匹配"转向"Agent 编排 + 工具调用"。底层逻辑和红队自己的武器库自动化是同构的——MCP 协议、统一编排、容器化执行面。这套范式如果成熟,未来红队工具链大概率也会长成类似形态:AI Agent 当调度层,传统 PoC 工具 / 漏洞库 / 协议 fuzz 当 MCP 后端。
需要我针对某个具体组件(比如 Worker 隔离安全性、YoungFlow 编排逻辑、DeVeye 浏览器指纹规避)展开分析吗?