文章总结： 腾讯玄武实验室在BlackHatUSA2026分享用LLM挖掘0-Day漏洞的方法：从历史N-Day补丁中提取根因与安全不变量，转化为可搜索模式，泛化搜索变体，配合验证闭环，两个月内在Chrome和Android挖出100+漏洞，并将7个高危漏洞串成攻击链。该方法可迁移至其他项目，LLM不会取代安全研究员。 综合评分： 92 文章分类： 漏洞分析,AI安全,红队,移动安全,安全工具

腾讯玄武的 0-Day 引擎：LLM 两月挖出 100+ Chrome 与 Android 漏洞

原创

AIxSec69 AIxSec69

AIxSec69

2026年9月13日 00:02 美国

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

腾讯玄武的 0-Day 引擎：LLM 两月挖出 100+ Chrome 与 Android 漏洞

来源：Black Hat USA 2026 Briefing（8 月 6 日 2:35pm，Oceanside A）

标题：The 0-Day Engine: Finding 100+ Vulns with LLMs in Chrome and Android

作者：Fangang Bu（Povcfe）、Huiming Liu，腾讯安全玄武实验室安全研究员

适合读者：漏洞挖掘工程师、Android/Chrome 安全研究者、对 LLM 在安全领域落地感兴趣的人

简介：传统 fuzzing 对逻辑漏洞几乎是瞎的，不崩就不会报。静态审计缺规则，人工审计又跟不上 3000+ 历史漏洞的模型积累。腾讯玄武实验室的卜凡港和刘慧明提了一个不同的思路：把历史 N-Day 补丁当成”漏洞模型训练集”，用 LLM 提取根因和安全不变量，再泛化搜索 0-Day 变体，配合工具链做逐阶段验证。两个月内在 Chrome 和 Android 里挖出 100+ 零日漏洞，并把这批漏洞中的 7 个高危串成了一条”看不见的主权者”攻击链，在完全补丁的 Pixel 设备上实现了无 Root 提权、窃取 Web3 助记词、付款码和持久化摄像头监控。

◆ ◆ ◆

为什么是逻辑漏洞

fuzzer 不报 crash，不代表代码安全。

Android 的逻辑漏洞，slides 上列了三大类。第一类是权限提升与授权：权限绕过、特殊应用访问、While-In-Use 滥用。第二类是 UI、Activity 与多用户安全：Activity 与 Intent 伪造、UI 混淆（tapjacking）、多用户与隐私空间隔离。第三类是设备管理：企业策略绕过。

▲ Android 逻辑漏洞的三大类：权限提升、UI/多用户安全、设备管理（来源：Black Hat USA 2026 Slides）

这些都不是内存破坏型漏洞，没有段错误，没有 SIGABRT。fuzz 对它们无效。演讲者给了一个很准的表述：For Android, no code execution needed. The boundary break is the impact。不需要先拿到代码执行，边界被打破本身就是影响。

AFL 那套模型是”投喂输入 → 目标崩溃”，逻辑漏洞根本不崩，自然抓不到。

CodeQL 这类静态审计的短板也摆在那：反射调用、函数指针、跨进程通信链路，规则覆盖不到。slides 上原话列了两条，reflection calls、function pointers，后面跟着一个省略号，再补一句 Lack of many rules。写规则的人少，需要覆盖的模式多。

▲ 3000+ Android 历史漏洞（2016 至今），没人能把所有漏洞模型都装进脑子（来源：Black Hat USA 2026 Slides）

这个问题在 3000+ Android 历史漏洞（2016 年至今）面前被放大了：没有任何一个研究员能把所有漏洞模型都装进脑子。

但换个角度看，这 3000 个漏洞本身就是一座金矿。

从 N-Day 补丁到 0-Day 变体

演讲者给了一个很具体的例子：基于伪造身份字段的授权绕过。

这个漏洞模型从 2020 年的 CVE-2020-0107、CVE-2020-0246 起步，2021 年 CVE-2021-0319，2022 年 CVE-2022-20223、CVE-2022-20455，2023 年 CVE-2023-21266、CVE-2023-40105、CVE-2023-40127，2024 年 CVE-2024-0015，2025 年 CVE-2025-0086、CVE-2025-48537、CVE-2025-48585，一路翻版到现在。补丁修了一个点，同一个模式换个文件、换个参数路径，又来一遍。

“Bug 被修了，模型在重复。”卜凡港在 slides 上写了这么一句话。

他们的做法是把每一笔 N-Day 补丁变成可搜索的漏洞模型。slides 上的原话是：几千个修复，变成几千个可搜索的漏洞模型。完整链路是”根因 → 安全不变量 → 可搜索模式 → 变体候选”。流程分三步：

第一步，diff 补丁，提取根因和安全不变量。不是简单地看改了哪行代码，而是问”这个补丁试图让什么条件始终成立”，这就是安全不变量。

第二步，把不变量转成搜索模式。可以是 primitive-driven（按原语搜索，比如哪个函数接收了未经校验的 Extra），也可以是 role-driven（按组件角色搜索，比如所有处理 Gatekeeper Password 的 Settings 子页面）。

第三步，在大规模代码库中泛化搜索变体。

整个方法的起点，演讲者用一句话收尾：Generalization finds candidates. Verification makes them real。翻过来就是，泛化找到候选，验证让它们成真。

大规模代码库怎么喂给 LLM

这里有一个工程上绕不开的问题：AOSP 的代码量，一个 LLM 的 context window 远不够用。

具体是三个坑：context window 有限，分析目标太多会扯散注意力，函数调用链太深让深度分析做不动。

他们的方案是任务分解。一句话概括：一个 LLM session，一个简单任务。

举个例子，如果要分析所有通向 system() 的调用路径，传统做法是把整个代码库抛给模型：模型先是被巨量代码把注意力打散，再被深层调用链把分析深度拉低，最后什么都分析不出来。

玄武的方案是把任务拆成三层循环。第一轮（Cycle 0）只做控制流定位，找到所有 call site，标出深潜点；第二轮每个深潜点起一个独立 session 做小范围精确分析；第三轮合并结果。每一轮只做一件事，context 不溢出，分析深度保住了。

这个架构还有一处设计：每个阶段都有验证。

验证闭环

LLM 输出”这里可能有问题”是起点，不是终点。

他们的验证流水线包括：编译测试 app 和 framework 模块 → ADB 部署触发 → Frida 和系统监控做运行时状态核验。每一步失败都会把信号回传给上一环，让模型修正分析路径。这一步不是”跑一遍确认”，而是”每一遍都有可能让模型变得更好”。

▲ 验证闭环：编译构建、ADB 部署触发、Frida/系统监控运行时核验（来源：Black Hat USA 2026 Slides）

这个闭环的产出相当猛：两个月，100+ 零日漏洞，全部报给 Google VRP，很多评了高危。

更值钱的是这套方法的迁移性。slides 上写着”解决一个问题，然后把它复制到更多项目”，适用范围列了 Android、Chrome、Firefox，还有开源项目。它不是一个给 Android 定做的一次性工具，是一条可以横向铺开的流水线。

他们把这批漏洞里的 7 个高危串成了一条叫”Invisible Sovereign”的攻击链。在完全打补丁的 Pixel 上，无需 Root，就能窃取 Web3 助记词和付款二维码，还能做持久化摄像头监控，直接废掉企业 DPC 策略。

两个实例：N-Day 是怎么长出 0-Day 的

方法论讲再多，不如看两个真实 diff。

第一个是 PIN 锁绕过。N-Day 是 CVE-2025-48541，修在 FaceSettings.java。修复前，mToken 直接从 Intent 里取，谁都能传；修复后加了一个判断，只有当调用方是 Settings 自己（callingPackage 等于 activity.getPackageName()）时才允许读这些 Extra。

同一个模型，被他们的搜索翻出了 0-Day 变体：BiometricsSettingsBase.java。这个类里有一行 if (BiometricUtils.containsGatekeeperPasswordHandle(getIntent()))，判断 Intent 里有没有 Gatekeeper 密码句柄，同样没校验调用方是谁。修复加了一个 mAllowInternalExtras 标志，只有 Settings 内部调用时才为 true，才放行这条路径。

第二个是 UI 混淆。N-Day 是 CVE-2022-20230，修在 KeyChainActivity.java。这个类把 uri.getAuthority() 直接拼进”请求服务器”的提示文案，攻击者能传一个 authority 长得像可信站点的 URI。修复用 Uri.encode() 把 authority 编码掉。0-Day 变体出现在 RequestManageCredentials.java，同样是把应用标签直接 loadLabel() 显示，修复改成 loadSafeLabel()。

两个案例讲的是同一件事：补丁只堵了”这一个点”，同一类”信任外部输入”的模型在相邻组件里照样活着。这就是 N-Day 能长出 0-Day 的原因。

那 LLM 会取代安全研究员吗

▲ 开场提问：Will LLMs replace security researchers?（来源：Black Hat USA 2026 Slides）

不会。

演讲者用 AFL 做了类比：AFL 诞生之后开启的是 fuzzing 时代的安全技术革命，不是研究员失业。LLM 现在也在改变安全研究的方法论，但核心价值从来没变：发现问题、验证问题、解决真实世界的安全问题。

工具会一直进化，但驱动工具的始终是人。

◆ ◆ ◆

原文链接：https://www.blackhat.com/us-26/briefings/schedule/#the-0-day-engine-finding-100-vulns-with-llms-in-chrome-and-android-53073

免责声明：

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

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

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

本文转载自：AIxSec69 AIxSec69 AIxSec69《腾讯玄武的 0-Day 引擎：LLM 两月挖出 100+ Chrome 与 Android 漏洞》