MobileCybench：用可执行探针给智能体挖洞能力打分，顺手揪出 23 个未公开漏洞

智能体帮人挖漏洞，已经不是新鲜事；怎么客观比较不同智能体「挖洞」的本事，却是件难事。一篇题为《MobileCybench》的论文（arXiv 2609.23980）给出一套评测范式：用可执行探针给漏洞报告打分。思路是，一条上报的漏洞如果只依赖应用特定的安全属性，人工核对成本高；他们改为写「探针」——对安全属性的可执行检查。评测时把上报的攻击在应用上重放，再跑探针：探针被触发，既证明攻击成功，也指明它违反了哪条安全属性。关键在于，探针编码的是属性而非某个已知漏洞，所以它能发现写探针时还不存在的漏洞。论文把这个框架落成 MobileCybench：13 款 Android 应用、495 条由作者编写并复核的探针、5 个编程智能体。

实测的设定分两维：智能体扮演恶意 App 装在受害者设备上，或以低权限账号远程攻击，各自再分「只有混淆后的 APK」与「拿到应用源码」两种。读数上，只给混淆 APK 时，表现最好的智能体 OpenCode 配 GPT-5.6-Sol 在恶意 App 设定下触发了 53.8% 应用的探针，远程攻击者设定下为 16.7%；拿到源码后，跨所有智能体与两种设定的触发率从 28.8% 升到 32.8%。这些数字说明，源码可见度对挖洞帮助有限，真正的瓶颈在应用的攻击面与探针覆盖。更出人意料的是跑基准本身顺带发现的：整个过程揪出 23 个此前未公开漏洞，多数已获维护者确认。

把视角拉到评测方法论本身，MobileCybench 的点在于它把「发现漏洞」从一件依赖专家手感的事，变成了可重复、可横向比较的实验。过去评一个智能体挖洞强不强，往往看它报出了几个酷炫的零日；但零日数量受目标选择影响太大，跨智能体比不出公平。探针把判分标准钉在「安全属性是否被违反」上，谁触发得多、触发在哪类属性，一眼可比较。这正是智能体安全从演示走向工程该有的样子。判分公平这件事，往往比一次惊艳的零日更有长期价值，也更能让厂商的安全宣传被客观核对，而不是停在演示视频里。 这篇和本栏目早年覆盖的「智能体自动挖出 ffmpeg 零日」不是同一条叙事，注意区分。那篇讲的是一个具体工具在特定目标上挖到了真实零日；本篇的贡献在评测方法论——用探针把「漏洞报告」从依赖人工的安全属性判断，变成可重放、可自动判定的检查，从而能横向比较不同智能体的挖洞能力，并顺带产出新漏洞。对安全团队，这套思路有直接的迁移价值：与其只看智能体「报了什么」，不如给关键业务应用预置一批属性探针，把智能体的发现能力变成可量化、可回归的巡检。对应用厂商，论文提醒的是另一面——把源码捂紧，并不等于攻击者挖不动，混淆 APK 下的触发率仍过半。 当然，基准有边界。495 条探针由作者编写并复核，覆盖的是这 13 款应用的安全属性，不等于全行业 Android 生态的漏洞地图；触发率衡量的是「探针被满足」，不直接等于可利用的严重程度，落地时还要结合人工分级。更有意思的长期信号是：智能体既在被拿来攻（本篇与护栏绕过那篇），也被拿来守（用探针做可持续巡检），同一套能力在攻防两端同时成熟。把 MobileCybench、护栏绕过研究与评测成熟度盘点摆在一起，智能体安全的三个层次就清楚了——攻方自动化、守方自动化、以及「我们到底有没有在测真危险的路径」的元问题。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。