导语：当大多数安全研究员还在用手工代码审计的方式挖掘漏洞时，韩国一名安全专业学生已经用AI工作流，在Grafana、Nextcloud、Matomo等知名开源项目中连续发现了十余个0day漏洞，拿到了可观的赏金。这不是概念验证——是真金白银的战果。
一、动机：为什么我想用AI找漏洞
在大学里，我的网络安全学习一直围绕CTF（夺旗赛）和攻防演练展开。在受控环境中找到漏洞并成功利用，确实很有成就感，但我始终渴望在”真实世界”中发现漏洞。
加入韩国网络安全培训项目BoB（第14期漏洞分析方向）后，我意识到安全行业的范式正在转变。导师们提到，AI在黑客领域的能力正在迅速提升，未来将接管安全行业的很多环节——有效利用AI将成为黑客的核心技能。目睹AIxCC（AI网络安全挑战赛）后，我更加确信：”AI用于安全”很快会成为主流。
这种信念随着AI的进化不断强化——从简单的Web UI聊天机器人，到Claude Code、Codex这类CLI工具，再到MCP（模型上下文协议）的出现，以及AI在漏洞赏金平台上摘得榜首……一切都在印证这个趋势。
二、目标选择：为什么我放弃了内存漏洞和黑盒测试
最初我也考虑过内存漏洞和黑盒服务器赏金项目，但最终基于现实原因做了调整。
内存漏洞方向：我构建了一套内存漏洞专用工作流，也找到了一些OOB（越界访问）和栈溢出崩溃。但Google OSS VRP这类项目很少接受单纯的崩溃，它们要求完整的利用链，能完全破坏系统的完整性或机密性。由于安全策略限制，用AI自动化这个过程目前非常困难。加上我的Web渗透背景比二进制漏洞利用更强，在内存漏洞方向上我没有足够的竞争力。
黑盒服务器赏金：我暂时搁置了这个方向，因为存在一定风险——AI在扫描时可能不安全地发送攻击性Payload，导致服务器崩溃。（美国Theori公司的Xint或xbow可能掌握安全扫描的know-how，但我还没到那个水平。）
最终，我选择了我最熟悉的大型Web开源项目：Nextcloud、Matomo和Grafana。这些项目的代码完全公开，通过Docker可以轻松本地化部署复现，而且我相信LLM的上下文理解能力，在发现复杂业务逻辑漏洞方面会远超人类肉眼审计。
三、架构设计：省钱的智能路由
我尝试了各种工作流，目前主要使用的两个工作流有一个共同特点：漏洞发现和误报验证两个阶段严格分离。核心思想是：不要在整套流程中都用最贵的模型，而是在每个阶段将数据高效路由到合适的模型。
这个架构的灵感来自Theori公司在AIxCC中的”RoboDuck”案例。RoboDuck使用模糊测试（消耗更多Token），据说每小时成本超过1000美元。这让我意识到：为了保证可持续性，我不能什么都用顶级模型，必须按需组合。
在对比各种低成本LLM基准测试时，我在GeekNews上看到了一篇关于GLM模型的文章，它的性价比看起来非常出色。在GLM系列中，最近发布的GLM-5比GLM-4.7性能提升约20%，但Token消耗是后者的三倍。由于Web漏洞检测往往需要发现的是IDOR这类逻辑漏洞，而不是需要高度复杂推理的问题，我决定：提高便宜模型的调用频率，比用稍微好一点但贵三倍的模型更有效。于是，我选择用性价比极高的GLM-4.7作为主力工作引擎。
三级漏斗架构：
- 第一层：发现（GLM-4.7）：搜索潜在漏洞候选。在这个发现阶段，我通过调整提示词创建了多个工作流变体。
- 第二层：半筛选（GLM-5）：用性能更好的GLM-5，从第一步生成的候选中过滤掉明显的误报。
- 第三层：终筛（Codex 5.3）：存活的候选提交给顶级模型Codex 5.3进行最终验证。
通过第三层验证的漏洞，会通过Discord发送告警，并将漏洞报告上传到Notion。
上传报告后，我总会手动复现验证每一项。由于Codex验证后仍可能存在误报，最终报告严格基于我的手动复现结果来撰写。
四、提示词工程：如何把误报率打下来
在运行工作流的早期，误报相当多，所以我不断实验和改进各种提示词来解决问题。
大多数误报的产生，根源都在三个要素之一存在缺陷。因此，我不得不强制AI在验证时评估这三个要素：
- 攻击者条件（Attacker Condition）：攻击者必须处于什么网络位置（内网/外网），需要什么权限（未认证/管理员/访客），以及必须注入什么特定输入才能使攻击成功。
- 服务器条件（Server Condition）：服务器的先决条件，比如是否需要启用特定插件、默认配置是什么，或者漏洞是否只在特定操作系统/环境下触发。
- 安全影响（Security Impact）：不能只说”危险”，而要基于CIA三元组（机密性、完整性、可用性）描述——它是否能导致数据泄露、拒绝服务（DoS），还是仅仅是简单的信息泄露。
很多人试图通过在提示词中”询问”AI来解决这个问题，比如”请考虑攻击者权限”或”注意服务器配置”。但LLM天生是懒惰的。像”考虑”这种模糊指令，在推理过程中很容易被跳过或一笔带过。强制AI在回复中明确输出这三个要素，反而迫使其系统性地分析它们，误报率大幅下降。
解决这三个问题后，一类新型误报又浮出水面：那些在源代码层面看起来像漏洞，但实际上是该开源项目安全模型下的预期行为或超出范围的问题。我更新了提示词，要求AI搜索项目的官方安全文档和政策，验证它究竟是真正的漏洞还是设计如此。
通过这个过程，工作流能够清晰区分Bug和漏洞，漏洞分析工作的误报率显著降低。
五、实战成果：AI找到了哪些漏洞
这个项目带给我的一个重要体会是：AI在发现IDOR和业务逻辑漏洞方面出乎意料地擅长。传统扫描器只是追踪数据流，但AI理解”上下文”——API的用途及其应该运行在什么样的安全模型下。
如果让人工分析，需要将数万行API路由代码与权限引擎的复杂交互进行交叉引用。这不仅耗时耗力，而且人类在扫描数千个参数后注意力会下降，很容易漏掉那个关键的缺失检查。AI不会疲劳，它会系统地将每个API定义与安全模型进行交叉比对，在捕捉人类容易忽略的细微逻辑漏洞方面展现出压倒性的优势。
最具代表性的案例，是用这个LLM工作流在Grafana的仪表盘权限管理API中发现的权限提升漏洞——CVE-2026-21721。
漏洞描述
Grafana允许对每个仪表盘设置单独权限（读/写/管理员）。在正常安全模型下，用户只能对自己被指定为”权限管理员”的特定仪表盘调用权限控制API。
然而AI发现的漏洞是：Grafana的仪表盘权限API（GET/POST /api/dashboards/uid//permissions）没有验证目标仪表盘的Scope。
- 根因：调用内部权限验证逻辑
ac.EvalPermission时，没有传入目标仪表盘的UID scope作为参数。它只检查用户是否拥有dashboards.permissions:read/write动作权限。因此，只要用户在系统中拥有至少一个仪表盘的管理员权限，就获得了执行dashboards.permissions:write的有效权限。由于服务器不检查这个权限指向哪个仪表盘，攻击者可以读写所有其他原本无权访问的仪表盘的权限数据。
影响
这是一个严重的权限提升漏洞：拥有某一个特定仪表盘管理员权限的用户，可以任意劫持组织内其他敏感仪表盘的控制权。通过给自己分配其他仪表盘的管理员权限，攻击者能完全访问之前无法获取的数据。
最终，该漏洞被编为CVE-2026-21721（CVSS 8.1）。在庞大的代码库中检查所有权限时，人类安全工程师可能会不小心忽略”Why wasn’t the UID scope passed as a validation argument here?”这样的问题，但AI准确地定位了这个安全引擎中的逻辑不一致。
其他0day漏洞一览
已获CVE的漏洞：
- CVE-2025-66514，CVSS 5.4 / Nextcloud Mail XSS（已获赏金）
- CVE-2025-66558，CVSS 3.1 / Nextcloud twofactor_webauthn 认证不当（已获赏金）
- CVE-2026-0994，CVSS 8.2 / protobuf DoS
- CVE-2026-21721，CVSS 8.1 / Grafana 权限提升（已获赏金）
- CVE-2026-22922，CVSS 6.5 / Airflow 特权API错误使用（已获赏金）
- 更多CVE pending……
仅获赏金（未颁发CVE）的漏洞：
- Nextcloud Contacts（预发布版），CVSS 6.5 / IDOR（已获赏金）
- Matomo，安全问题通过HackerOne报告（已获赏金）
- Matomo官方插件，安全问题通过HackerOne报告（已获赏金）
- Matomo官方插件，安全问题通过HackerOne报告（已获赏金）
- Matomo官方插件，安全问题通过HackerOne报告（已获赏金）
- Grafana，安全问题通过Intigriti报告（已获赏金， CVE pending）
- Owncloud，安全问题通过YesWeHack报告（已获赏金， CVE pending）
- Discourse，安全问题通过HackerOne报告（8个赏金， CVE pending）
六、未来展望：AI时代，人类的出路在哪里
直接用AI工作流搜索漏洞的过程中，一个更深的问题在我脑海中形成：”如果AI已经这么强了，我的未来还有位置吗？”距离我进入就业市场还有三年多，届时世界将充满远比今天更先进的AI。
虽然我对整个安全行业还不够了解，但我的个人判断是：红队的简单漏洞发现任务将大幅减少。主流趋势将转向AI在开发工作流中实时进行安全诊断，从源头阻断漏洞；同时AI漏洞分析智能体将积极猎取Bug。不是所有红队都会消失，但我相信AI将接管他们目前处理的绝大部分手工任务。
然而，我不认为人类角色会完全消失。如何根据业务场景制定漏洞修复策略，或者建立和运营公司独有的安全策略——无论AI多先进，这些领域都需要人类的讨论和决策。
因此，我计划将学习方向聚焦在两个主要方向：
- AI用于安全：学习设计和构建漏洞猎取型AI工作流，就像这个项目一样。
- 蓝队与安全架构：超越纯粹的进攻（红队）技能，理解现实世界的企业安全政策和基础设施。
当然，这只是一个安全专业学生的个人推测，并非行业资深人士的看法。但与其抵抗即将袭来的AI浪潮，我相信：最有效地掌握这个工具的黑客，将拥有显著的优势。
出处：How I Found Open Source 0-days with an LLM Multi-Agent Workflow， 作者Hyunseo Shin，博客地址：https://blog.cykor.kr/2026/02/How-I-Found-Open-Source-0-days-with-an-LLM-Multi-Agent-Workflow
暂无评论内容