安全研究员 Kasra 搭建了一个存在已知漏洞的图书评论应用，用它测试了十余款主流大模型能否「黑」进去——最终烧掉约 1500 美元 API 调用费用，结果颇有争议。
为什么做这个测试
Kasra 在日常安全审计中多次遇到一类漏洞：开发者把 Firebase 的凭证文件（google-services.json）直接打包进 APK 分发，同时将 API 层做得很严实，以为这样就安全了。但问题是，Firebase 本身支持直接注册和读写数据库，只要拿到凭证就能绕过 API。这类漏洞被归为「访问控制失效」或「对象级授权缺失」，在真实项目中相当常见。
Kasra 因此设计了一道 CTF 风格的挑战：参与者（LLM）拿到 APK 和后端代码后，需要利用 Firebase 直接读取目标用户的私有书评，找到藏在里面的 flag。
各模型表现差异悬殊
测试用 $10 单次上限、两小时超时、同样的 temperature（0.7）和高思考模式，但使用了不同的运行框架（pi + goal-x 插件，或 Claude Code 的 -p 模式），且并非所有模型都跑满 10 次——费用在后期成为瓶颈。
表现最好的 GPT 5.5 完成了 7/10 次，成功率最高，且几乎每次都直接锁定 Firebase 而非在 API 层浪费时间。Deepseek V4 Pro 3/10，Claude Sonnet 4.6 和 Opus 4.8 各 2/10（Opus 多次接近答案，但安全护栏在中途终止了会话）。
得 0 分的选手原因各异：Gemini 3.1 Pro Preview 立即因安全理由拒绝；Deepseek V4 Flash 和 MiniMax M2.7 发现了 Firebase，却试图用 Firebase 凭证去调用 API 而非直接操作数据库，属于解题方向错误；Step 3.7 Flash 把正常功能误报成漏洞后收工。
部分跑了几次的模型里，GLM 5.1（1/4）烧钱飞快，作者表示「可能不会再用」；Qwen 3.7 Max（0/6）在本地测试时是唯一非 GPT 模型成功完成挑战的，但在大规模运行中一次也没复现，单次消耗高达七百万 token。Kimi K2.6 在唯一一次运行中成功破解，但因 API 不支持并发代理且配额有限未继续测试。
这说明什么
需要注意的是，这并非严谨的科学评测。约一半费用花在了测试失败和未完成的运行上，各模型用的运行框架和 API 提供商不尽相同，OpenAI 账号已获安全研究授权（GPT 因此没有因安全策略直接拒答）。
核心结论在于：LLM 在安全研究场景下确实能自动找到某些真实漏洞，但成功率高度依赖模型本身以及是否配备了合适的提示框架和迭代机制；部分模型的安全护栏会误伤正当测试，而另一些模型则会在错误的方向上反复撞墙。
编注：信源为安全研究员 Kasra 的个人博客，内容包含部分快讯式数据罗列，主线为各模型在 Firebase 访问控制漏洞上的实测结果对比；作者未提供控制组，测试框架不完全统一，且约一半费用用于未纳入统计的失败运行，结论仅供参考，不宜视为模型安全能力的权威排名。