VulnHunter:AI 驱动的自动化漏洞发现 Agent 平台

2026-10-01 14:01:42 1 108

AI 驱动的自动化漏洞发现 Agent 平台

VulnHunter 是一个开源的 AI 漏洞挖掘工作台,集成了自动化目标分析、AI 辅助漏洞发现、对话式调查、POC/EXP 生成验证、审核工作流和报告交付,支持自部署运行。


📸 界面预览

🎛️ Dashboard 总览

dashboard.png

🔍 漏洞发现

findings.png

🤖 AI Chat 助手

chat.png

💥 POC/EXP 验证

poc.png

📊 审计报告

report.png


⚡ 为什么选择 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,无自动转开源日期。

🤝 参与贡献

欢迎贡献!当前贡献指南正在完善中,基本流程:

  1. 提交 Issue 描述 Bug、功能建议或文档改进
  2. Fork 后开发,保持改动聚焦
  3. 提交前确保 pnpm build && pnpm test 通过
  4. 提交 Pull Request

请勿提交:密钥、私有扫描数据、客户数据、运行时产物。


⚠️ 安全与合法使用声明

VulnHunter 是面向安全研究与授权测试的工具。

仅可对您拥有、或已获得明确授权进行测试的系统、代码库与服务使用本软件。

禁止将本软件用于:

  • 未经授权的漏洞扫描、渗透或攻击;
  • 挖掘、利用漏洞从事任何违法犯罪活动;
  • 对第三方系统造成破坏、窃取数据、勒索或拒绝服务等侵害。

使用本软件即表示您理解并同意:因非法或未授权使用所产生的一切后果由使用者自行承担,与项目维护方无关。

关于作者

whoami121篇文章195篇回复

勤快的搬运工。

评论1次

要评论?请先  登录  或  注册
  • 1楼
    昨天 14:02

    VulnHunter 攻击方视角分析

    工具定位与红队价值

    VulnHunter 本质上是一个AI 编排的 SAST 增强工作台,把传统静态分析里最耗时的"语义理解 + 利用验证"两段用 LLM Agent 接管。它的攻击侧价值不在"扫描"这一步,而在于自动化产出可利用 POC——传统 SAST 输出的是告警,VulnHunter 试图直接给出"这条漏洞能不能打"。

    对红队来说,这意味着:

    • 漏洞发现 → POC 验证 → 报告这条链被压缩成一个 CLI/Chat 操作,省掉 Burp + sqlmap + 自己写脚本切换的来回
    • MCP 工具协议让 AI 能直接调用外部能力(HTTP 请求、命令执行、文件读写),而不是只生成代码片段后人工跑——这是和普通 CodeQL/Semgrep 的根本差异
    • DeVeye 浏览器自动化暗示 POC 验证可以模拟真实用户交互场景,不只是协议层的发包

    架构层值得关注的点

    从攻击方角度看这套架构有几个有意思的设计:

    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),完整的攻击链是:

    1. /module/api.php?mobile/webNasIPS 泄露 PWD 路径
    2. 带伪造的 AUTHORIZATION + SIGNATURE 头
    3. raidtype 参数注入命令 ; ; |

    这种多步、依赖特定认证头、链式触发的场景,AI Agent 要自动串起来并不容易。如果 VulnHunter 的 POC 验证只覆盖"单步发包看响应"这一类(SQL 注入反射、SSRF 回带、未授权访问),那它对真实打点的帮助仍然有限——红队拿到这类"漏洞"还得自己手工构造利用链。

    对比传统工作流的优势区间

    VulnHunter 的 Chat + MCP 模式真正的甜区是:

    • 大批量资产快速过筛——一个项目丢进去,让 AI 跑通扫描,输出可利用漏洞清单
    • 零日/小众框架的代码审计——传统 SAST 规则没覆盖的新框架,AI 靠上下文能给出方向
    • 报告自动化——客户验收时报告这块能省大量时间

    弱势区间:

    • 业务逻辑漏洞——AI 看到的还是局部代码,跨模块的状态机/权限链它拼不出来
    • 运行时漏洞——架构是纯静态分析(+ 浏览器自动化),没看到动态插桩/sandbox 执行样本的环节
    • 反编译/二进制审计——架构里没有逆向 worker,定位偏 web/源码型场景

    红队实战使用建议

    如果要在真实渗透中引入这套工具:

    1. 喂目标前先脱敏源码中的客户信息——源码会进 MinIO 持久化
    2. 隔离部署到独立网络——worker 容器默认在 10.177.0.0/24 子网,避免和内网混跑
    3. POC 输出当方向参考,不要直接当最终 payload——AI 生成的脚本有签名特征,且可能不完整(参考 t00ls 那篇 ASP 站点案例,作者最后也是发现"解密第二个管理员"这种 AI 容易漏的细节)
    4. DeVeye 的浏览器指纹要清理——浏览器自动化验证会留下和 Selenium/Puppeteer 一致的特征,目标侧 WAF/风控可能识别

    一点延伸思考

    从工具演进角度看,VulnHunter 这类平台的出现说明漏洞挖掘正在从"规则匹配"转向"Agent 编排 + 工具调用"。底层逻辑和红队自己的武器库自动化是同构的——MCP 协议、统一编排、容器化执行面。这套范式如果成熟,未来红队工具链大概率也会长成类似形态:AI Agent 当调度层,传统 PoC 工具 / 漏洞库 / 协议 fuzz 当 MCP 后端。

    需要我针对某个具体组件(比如 Worker 隔离安全性、YoungFlow 编排逻辑、DeVeye 浏览器指纹规避)展开分析吗?