文章总结： 本文通过对比四种AI渗透测试方法发现，本地开源模型配合定制框架能稳定发现PHPIPAM的LFI漏洞和myVesta的RCE漏洞，而云端方案成本高且效果不稳定。关键结论是方法框架比模型本身更重要，建议通过分文件审查降低任务复杂度。文章还提供了实战漏洞验证细节和硬件资源利用方案。 综合评分： 85 文章分类： 渗透测试,AI安全,实战经验,漏洞分析,安全工具

本地AI做渗透测试：模型不重要，方法才关键

幻泉之洲

2026年6月30日 10:19 北京

在小说阅读器读本章

去阅读

本文记录了作者用四种不同方法找出同一漏洞的对比实验。结果很有意思：最贵的云端方案花了30美元没找到，本地跑的开源模型配合定制框架却次次命中。关键是——你给模型搭建的“脚手架”比模型本身更重要。文中还顺手挖出了myVesta控制面板的真实RCE漏洞，验证了这套方法的实战价值。

背景

距离我上一次尝试类似的东西[1]已经过去一年。这一年里，模型能力和攻击手法都进步了不少。

Anthropic发表的研究报告炒得很热，但成本和隐私还是绕不过去的坎。如果没法保证审查的彻底性，安全审计就会变成一种赌博——你永远不知道这次扫描是不是“差一点就找到了”。

那种“再跑一次就好”的心态，做过渗透测试的人都懂。

于是我搞了个小测试：用四种不同方法去找同一个已知漏洞，看哪种方法最靠谱。

基准漏洞：PHPIPAM认证后的LFI

选的是一个经典的PHP本地文件包含（LFI）漏洞，出在PHPIPAM这个IP地址管理系统里。

漏洞逻辑很简单：控制器名称直接从用户输入里取，然后不做任何过滤就拼接进require_once。看这行代码[2]就明白了。

前提是API功能开启（默认关闭），并且你有有效凭证拿到API token。满足这两个条件，就能包含或执行服务器上任何以.php结尾的文件。

▲ 第二个请求里包含了我放进去的phpinfo()文件，证明漏洞可复现

这个漏洞是在没有补丁的情况下公开披露的，因为风险较低，而且PHPIPAM维护者没有回应。漏洞只影响开启API的实例（默认关闭）。默认影响也有限——没有上传任意.php文件的办法，也没有现成的可利用文件。如果你在用PHPIPAM，建议先关掉API。漏洞编号CVE-2026-12194[3]。

测试结果一览

先看结论。四种方法里，最成功的那种说明了一件事：你给模型的工具和流程，比模型本身更重要。

| 方法 | 找到了吗？ | | — | — | | Semgrep | 没 | | 云端GLM 5.1 + Strix AI代理 | 没* | | 云端SOTA模型 + 代码审查技能 | 有时候能找到 | | 本地AI + 定制框架 | 每次都找到 |

Semgrep：规则驱动的局限

直接semgrep scan --config auto跑了一遍，没识别出来。

当然你可以写自定义规则来抓这个模式。但老派SAST工具的痛点就在这：你只能为已知的危险模式写规则。没见过的漏洞类型？抓瞎。

GLM 5.1 + Strix：烧钱12小时的教训

接着试了Strix[4]，一个全自动化的AI渗透测试框架。开源，25000多颗GitHub星星，看起来挺唬人。

注意：官方文档推荐用GPT-5.4、Claude Sonnet 4.6或Gemini 3 Pro。我不想签无上限账单，所以选了便宜点的GLM 5.1，先观察token消耗。GLM 5.1的基准测试成绩跟推荐模型差不多，但这个对比仅供参考。

过程确实刺激。它自己克隆了仓库、遍历代码库、甚至自己装了应用来做动态验证。

大约12小时后，烧了将近6000万token，一份report.md摆在我面前。

没找到我们的LFI。老实说，这让我想起一条推文——花了大价钱买彩票没中奖的感觉。

GLM 5.1实际花了大概30美元（不少请求还走了免费推理服务）。如果换成Sonnet，费用在180到300美元之间。Opus再翻倍。我没兴趣花那个钱再试一次更贵的模型。

报告里列了一堆问题：API泄露敏感数据、存储型XSS、SSRF、越权、CSRF、二次SQL注入等等。有些是PHPIPAM威胁模型里“设计如此”的东西，有些看起来像误报，有些早就修了。

云端SOTA + 代码审查技能：时灵时不灵

换了个思路：用AI技能模板。所谓“技能”，本质上是个Markdown文件，给代理提供特定指令、工作流和专业知识。

我从社区贡献的安全审查技能开始改。

▲ 社区版安全审查技能模板：github/awesome-copilot[5]

改动包括：去掉依赖审计、密钥扫描和补丁建议步骤；把每种漏洞类型拆成独立子代理；在注入漏洞部分加了LFI的专项指引。

结果呢？高度不稳定。有时能找到，有时完全漏掉。

用Claude Code的Pro计划跑这个技能，体验很差。

看模型的思考过程，它自己决定不启动子代理来处理每类漏洞。

强制让它启子代理，瞬间撞上5小时会话限制。

后来在Cursor里用GPT 5.5试了几次，总算有一次找到了。

问题在哪？代码库一大，审查就不够彻底。找不找得到漏洞，很大程度上取决于代理决定读哪些文件、用什么关键词去grep。

有意思的是：只要把正确文件指给它看，几乎所有模型都能立刻认出漏洞。

但如果用技能模板让它“自己找”，马上触发拒绝——模型推理一圈后觉得任务太大，单次搞不定。

就算绕过拒绝，这玩法也太烧钱了。

换个思路：本地模型 + 定制框架

但是，如果只给模型一个源文件加上下文，而不是让它一口气审查整个代码库呢？任务难度降了不止一个量级，本地模型是不是就够用了？

我们的新方案：用一个小型本地框架替代单次大审查。框架逐个文件喂给本地模型，每次只给一个文件加上必要上下文。

对于每个源文件： | +–> 本地模型审查单个文件（+上下文） | +–> 写出结构化报告 | v 汇总所有报告 | v ??? | v 搞定

▲ 整体流程图

这种方法每次都找到了基准漏洞，没有失手过。

输出报告清晰标注了风险点：控制器参数从$_GET、$_POST、JSON body或XML body直接流进require_once()，没有任何路径校验，可以通过../遍历目录包含任意PHP文件。

这个代码库大概800个源文件，跑下来消耗了约1.2亿token。

局限也很明显：

• 吃token，如果没法本地跑模型会很贵。好在我们Project Black[6]本来就有跑hashcat的硬件用于渗透测试中的密码破解[7]，这硬件跑Qwen 3.6 27b配170k上下文也够用。
• 误报多。毕竟纯静态分析，没有运行时验证。可以把结果再喂给AI做可利用性验证，但那会更烧token。
• 缺乏威胁模型和业务上下文理解。测试中发现，对于更复杂的越权漏洞（比如OWASP Top 10里的Broken Access Control[8]），模型理解不了那些微妙的权限假设差异。

实战验证：myVesta的认证RCE

碰巧，就在我收尾基准测试时，一个用myVesta[9]的朋友发来消息。myVesta是个类似cPanel的网页服务器控制面板。

来得早不如来得巧。

8小时后，找到了一个认证后的远程命令执行漏洞。

背景说明：这类控制面板让普通用户能在共享服务器上执行有限的管理操作。如果存在认证RCE，意味着你注册个主机商账号就可能拿下整台服务器。而且命令是以高权限管理员身份执行的，不是你自己的用户。

问题出在一段遗留代码里：FTP用户名删除功能直接把Username参数传进了exec。

构造一个测试请求验证。

服务器上检查到了创建的文件，漏洞确认。

myVesta团队响应很快，号CVE-2026-12195[10]，修复提交在这里[11]。

还能继续挖吗？

能。还有更多漏洞在验证中，细节暂不公开，给项目方留修补时间。后面还会有东西出来。

最后说几句

本地AI模型的能力在持续提升，这些技术会落到更多人手里——这是好事。

我们团队在琢磨怎么把这套东西融入工作流程，如果能成，对客户来说意味着更快更彻底的渗透测试[12]。潜力很大，我们会继续折腾，看看本地AI能在哪些环节真正派上用场。

参考资料

[1] https://projectblack.io/blog/vibe-hacking-open-game-panel-rce/

[2] https://github.com/phpipam/phpipam/blob/137141d89a44e9979eb0df52427ec0e676077f03/api/index.php#L236

[3] https://www.cve.org/CVERecord?id=CVE-2026-12194

[4] https://github.com/usestrix/strix

[5] https://github.com/github/awesome-copilot/blob/main/skills/security-review/SKILL.md

[6] https://projectblack.io/

[7] https://projectblack.io/penetration-testing/internal-network-penetration-testing/

[8] https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

[9] https://github.com/myvesta/vesta

[10] https://www.cve.org/CVERecord?id=CVE-2026-12195

[11] https://github.com/myvesta/vesta/commit/95d7e43bf286d6881ca753dac93cb42d98cc7422

[12] https://projectblack.io/penetration-testing/

[13] https://projectblack.io/blog/local-ai-for-cyber-security/

免责声明：

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

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

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

本文转载自：幻泉之洲 《本地AI做渗透测试：模型不重要，方法才关键》