谷歌威胁情报团队在 2026 年 9 月 30 日发布了一份漏洞趋势报告，而所有人都在引用的那一句——由 AI 发现的漏洞里恰好 50% 会导致远程代码执行，而其余漏洞只有 26%——恰恰是你最无从据以行动的那一句：GTIG 没有为它公布样本量，而它自己的归属方法又挑中了当下那几家把智能体对准 OpenSSL 与内核的厂商。往下翻四节，埋着一个写着你名字的数字：八个月里，智能体框架与编排层有 782 个 CVE，几乎是前沿模型本身的九倍。今年挪动了的那份风险，在你的依赖树里，不在模型里。
速览
同一份报告里的四个数字，以及每一个究竟承得起什么。
| 数字 | 取值 | 有多扎实 | 它支撑得起什么 |
|---|---|---|---|
| AI 发现者的 RCE 占比 | 50% 对 26% | 原文照引，未公布分母 | 一个关于样本的假设，而非一项规划输入 |
| 每月披露量 | 5,045 → 10,740 | 2026 年 1 月到 8 月，GTIG 自有数据集 | 分诊负荷翻倍；有独立数据印证 |
| 到被利用的时间 | 4 天，单个 CVE | 单一个案，与公开 PoC 同日 | 大致就是前 AI 时代 2023 年的均值——不是加速 |
| 编排层 CVE | 8 个月 782 个 | 计数所得、按层归属、无人反驳 | 一条你大概还没有的补丁 SLA |
报告说了什么
《Vulnerability Discovery and Exploitation Trends in the AI Era》由 Robin Grunewald、Supriya Mazumdar 与 Kelli Vanderlee 执笔，覆盖 2025 年 1 月 1 日至 2026 年 8 月 31 日披露的漏洞。它的主要结论彼此一致，而在能够交叉核验的地方也大体站得住。
每月披露量在 2026 年内部翻了一倍——1 月 5,045，7 月 10,477，8 月 10,740。来自 NVD 数据源的独立计数还要更高（8 月为 12,291），这正是一个范围更窄的策管数据集该有的样子，所以方向上没有争议。被利用的漏洞数也在涨，从 2025 年月均 10.5 个升到 2026 年 1 至 8 月的 18 个，零日利用则涨得温和些，从月均 8 个到 11 个。而在那八个月里有 141 个各不相同的漏洞既被披露也被利用，超过了 2025 年全年的 127 个——同时也只占披露量的 0.23%，大约 431 个里有 1 个。
GTIG 对自己的基线相当谨慎，而相关报道并不如此。它指出自动化的 CNA 分配会抬高分母——仅描述里含有「Linux Kernel」的漏洞，在 2026 年 1 月至 8 月间就生成了约 5,000 个 CVE，且没有观测到任何在野零日——并且说明其风险评级是 GTIG 自己的，不是 CVSS 严重性。这两条说明都在削弱对这个趋势最简单的那种读法。
这个 50% 描述的是谁在跑智能体，而不是智能体找得到什么
读一读 GTIG 的归属方法，这个发现的性质就变了。一个漏洞有两条路进入「由 AI 发现」这个集合：被从各前沿 AI 研究项目那里直接接入的已确认披露所摄取，或者被程序化地从 CISA 公告、MITRE 记录与厂商安全公报里解析出「明确承认是自主智能体发现的」这一表述。两道筛子筛的都是披露实践。两者都没有观测发现过程。
于是这个样本就是「当下谁会在公告里这么写」——而在 2026 年，那是一份很短的名单。GTIG 点名 Hacktron AI 与 AISLE 作为它的锚点。AISLE 在 2026 年 7 月成为首个 AI 原生的 CVE 编号机构，发布过一连串 OpenSSL、curl 与 Wireshark 的发现；Hacktron 的公开工作是针对 C 与 C++ 面向网络软件的变体分析。那些目标是内存不安全的系统代码。内存不安全的系统代码产出内存破坏，而内存破坏产出代码执行。单凭目标构成就能预言这个结果，完全不需要任何关于智能体能力的主张。
GTIG 自己的解释是带着保留的——这种集中「很可能源自」智能体在 C/C++ 库、运行时与虚拟机管理程序之间穿行多步语义代码路径的能力。那是对同一个观测的一套能力叙事，而且它很可能是对的。问题在于，报告没有为「由 AI 发现」那一列公布 N，也没有为目标软件构成做任何控制，所以从外部无从分辨这两种解释。「恰好 50%」本身就是个提示：整齐的一半往往来自很小的分母。
同一年里也有相反的证据。VulnCheck 的《State of Exploitation 1H-2026》于 7 月底发布，把 1,061 个漏洞归为 AI 辅助发现，并发现其中 14 个——1.3%——被确认在野利用；其作者称这与同期所有漏洞大致相当，且低于历史均值。文中还引了 Anthropic 的 Project Glasswing：两万三千多项发现、126 个已发布 CVE、1 个被确认利用。
这两个结果其实并不冲突，而且值得不去上演一场假打。GTIG 测的是潜在影响类别；VulnCheck 测的是已实现的利用。「由 AI 发现的漏洞在纸面上更严重」与「它们被攻击的概率并没有更高」可以同时成立。GTIG 自己也承认了这一点：对由 AI 发现之漏洞的已确认利用，是「一个早期指标，而非一个已成立的趋势」。
「四天之内」大致就是 2023 年的常态
报告里那个范例是 CVE-2026-1731，BeyondTrust Privileged Remote Access 与 Remote Support 中的一个无需认证的 OS 命令注入，由 Hacktron 的研究智能体自主发现。GTIG 观测到一个威胁集群在公开披露后四天之内就在利用它，七天之内又有五个，利用后活动包括权限提升、数据外泄，以及投放 SNOWLIGHT、SPARKRAT 与挖矿程序。
四天听着像未来已来。把它放到 Mandiant 自己那条「到被利用的时间」序列上，它是不久的过去：平均 TTE 从 2018–19 年的 63 天降到 44 天、再到 32 天，而 2023 年那一批是 5 天——并且在那一批里，12% 的 n-day 在一天之内被利用，29% 在一周之内。2026 年一个四天的 n-day 正坐在 2023 年的均值上，而且比 2023 年最快的那八分之一还要慢。
直接的催化剂也不是 AI。利用是在一份公开的概念验证被贴出来的那一天开始的。那个四天的数字是从披露起算的，但它真正记录下来的是一个大约为零的「PoC 到被利用」间隔——漏洞管理里最古老的那种套路。把这份速度归因于该漏洞的 AI 出身，是 GTIG 并没有走的那一步因果推断，你也不该走。
没人引用的那个数字
现在说这份报告里关于本维基所谈之系统的那一部分。GTIG 数出了 2025 年 1 月至 2026 年 8 月间 AI 技术栈累计 2,076 个 CVE，其中一千五百多个落在 2026 年头八个月里。按层拆开看 2026 年：AI 编排与智能体框架 782、AI 网页应用与门户 230、推理与服务基础设施 212、模型安全公告 106、ML 框架与模型库 99、前沿模型 97、MLOps 与实验跟踪 39、向量数据库与检索 19。
把第一个和第六个数字并排放着看。编排层产出的 CVE 大约是前沿模型的八倍。这把注意力的分布整个颠倒了过来：模型是那个有系统卡、有安全评测、有红队报告、有厂商安全团队的东西。编排层则是那个在做原型时以一句 pip install 进来的东西，它握着凭据、拥有工具目录、坐在出站路径上。它是爆炸半径最大、而补丁纪律最差的那一层，而它如今是整个技术栈里增长最快的 CVE 类别。
诚实的那条说明是：数量不等于风险。数一个类别里的 CVE，部分数的是这个类别里有多少活跃的 CNA，而一个年轻、迭代很快、又刚获得扫描器注意的生态会很快铸出 CVE。GTIG 也报告说，对 AI 基础设施的零日利用压根没有被观测到，而那 2,076 个披露里只有寥寥数个被确认在野利用。所以这不是在说你的框架正在被攻击。它说的是你的补丁工作将从哪里来——而它已经开始了。
这周该改什么
上面这一切都不需要你对「智能体是否找得到更可怕的 bug」持有立场。它需要的是：知道你依赖什么，以及你换掉它有多快。
- 把编排层清册做出来。框架、每一台 MCP 服务器、网关、沙箱运行时、向量库、浏览器自动化。按版本锁定，每一项都有归属人。多数团队说得出框架，别的说不出——见智能体清册与注册表，用推导而不是用问卷来得到它。
- 专门为这一层定一条补丁 SLA，并照它度量。八个月 782 个 CVE，单这一层在整个生态里的到达率就是每天一两个；一个按季度的升级节奏不是一条政策，而是一份积压。智能体平台的漏洞管理讲的是这条 SLA 必须覆盖什么。
- 别再把「无需认证」当成唯一要紧的严重性。BeyondTrust 那个漏洞是前置认证的，所以它受到了关注。而你智能体技术栈里的那些，大多会是认证后的——而认证后正是智能体生活的地方：它早就在里面了，握着一个令牌，带着环境可达范围。爆炸半径是在这件事上活得下来的那个框架。
- 订阅你「装进来」的东西的公告，而不只是你「买进来」的。一台来自某个 GitHub 账号的 MCP 服务器没有公告源，也没有弃用政策。那是你早就做过的一个采购决定——第三方模型与供应商风险，以及讲安装路径的智能体供应链安全。
- 按摘要锁定，并且去核对那个摘要。披露量翻倍意味着被迫升级更频繁，而升级越多，升级本身成为那次入侵的机会就越多。锁定与校验。
如果你只做其中一件，就做清册。别的事情没有它都排不进日程，而清册正是那件把这样一份报告从一条头条变成一个工作队列的产物。
常见问题
那个 50% 的 RCE 数字是错的吗？
不是——它是从 GTIG 那里准确引来的，而且没有理由怀疑他们在自己样本上的算术。问题在于这个样本代表什么。由于「是否入选」取决于某份公告有没有明确把功劳记给一个 AI 智能体，这个集合便被少数几家在内存不安全系统代码上作业的高产厂商主导，而这本身就预言了一个 RCE 偏重的构成。
我该因为这份报告重排补丁队列吗？
不该按「AI 出身」这个信号来排，因为你压根观测不到它——公开 CVE 记录里没有 AI 归属字段，这一点 GTIG 自己也指出了。请改按那个「分层」的发现来重排：如果你的编排与智能体框架依赖不在漏洞管理范围之内，那是一个具体的缺口，而补上它不取决于任何有争议的主张。
披露量翻倍是否意味着风险翻倍？
不。GTIG 把「既披露也被利用」的比率放在 0.23%，大约 431 个里有 1 个，并把部分量增归因于自动化的 CNA 分配——八个月里约 5,000 个 Linux 内核 CVE，且没有观测到在野零日。可靠地翻了倍的是分诊成本。
为什么智能体框架里 CVE 这么多，而前沿模型里这么少？
一部分是真实暴露面——编排代码面向网络、处理不可信输入、握着凭据——一部分则是记账方式。模型侧的问题经常以公告形式处理，或者在托管服务里不申请 CVE 编号就静默修掉，而 GTIG 把这列为「公开数据低估」的原因之一。请把 782 对 97 读成一句关于「可打补丁、可追踪的缺陷住在哪里」的陈述，而不是一次安全性比较。
最值得加的那一项测量是什么？
你的编排层依赖相对其最新发布版本的平均落后天数，按每个已部署智能体汇报。它很便宜，它会在你真干活时移动，而它正是那个本可以提前告诉你「披露量翻倍你扛不扛得住」的数字。
延伸阅读
本维基内：
- 智能体平台的漏洞管理——这份报告所主张的那条补丁 SLA。
- 智能体清册与注册表——推导依赖清单，而不是去索要它。
- 智能体供应链安全——编排层最初是怎么装进来的。
- 漏洞修复智能体——数量问题的另一面。
- 未锁定的厂商默认值——为什么你的技术栈会在没有发布的情况下改变。
来源：
- GTIG — Vulnerability Discovery and Exploitation Trends in the AI Era，2026 年 9 月 30 日。
- VulnCheck — State of Exploitation 1H-2026，1,061 个 AI 归属漏洞里 1.3% 被利用的那个数字。
- Mandiant — 2023 年到被利用时间趋势，五天的均值与 n-day 分布。
- Mandiant — 2021–2022 年到被利用时间趋势，63/44/32 天那条序列。