AI 发现 FFmpeg 21 个零日；Chrome 修复 429 漏洞

本周有两件事在几天内接连发生。一个安全创业公司报告称，FFmpeg 中存在 21 个此前未知的漏洞；FFmpeg 是几乎所有处理视频的软件中都会用到的媒体库，这些漏洞全部由一个自主 AI 代理发现。

同一周，Google 发布了 Chrome 149，并修复了 429 个安全漏洞，这是单次发布中数量最多的一次。

只有 FFmpeg 的漏洞是由 AI 发现的。Chrome 的纪录则出现在 Google 调整赏金计划之后，以应对大量由 AI 生成的报告。机制不同，但压力相同：AI 正以前所未有的速度，把更多漏洞摆到必须处理它们的人面前。

FFmpeg 的发现来自 depthfirst。该公司的自主安全代理扫描了这个项目大约 150 万行 C 代码，产出了 21 个已确认的 zero-day，每个都带有可复现的 proof-of-concept 输入。

公司将这次运行的成本估算为约 1,000 美元。其中一些漏洞已潜伏 15 到 20 年；service-description-table 代码中的一个 stack overflow 可追溯到 2003 年，直到 23 年后才被触碰。

多数问题是解析器和 demuxer 中的 heap 或 stack overflow，涉及从 TS demuxer 到 VP9 decoder 等组件。depthfirst 表示，其中一些已经有 CVE 标识；其说明中列出了 9 个，分别是 CVE-2026-39210 到 CVE-2026-39218，并注明其余漏洞已修复但尚未编号。该公司还发布了 PoC。

另据单独消息，Chrome 149 修复了 429 个漏洞，创下单次发布纪录。其中 100 多个为 critical 或 high severity，大多是 use-after-free 和输入验证不足。

最严重的是 CVE-2026-10881（CVSS 9.6），它是 ANGLE 图形引擎中的 out-of-bounds read and write，攻击者可借助特制页面逃逸 sandbox 并在主机上运行代码。Google 为此支付了 97,000 美元。

高严重性漏洞中，大多数来自内部发现：约 90 个 high-severity 漏洞里，只有 10 个来自外部研究人员，22 个 critical 漏洞中有 19 个是 Google 自己发现的。与 AI 的关联更多体现在数量，而不是作者身份。

Google 并未把这 429 个漏洞与 AI 直接关联；公开可见的信号是它在 4 月进行的赏金计划调整。这一调整是为了应对 AI 生成提交的激增，并且现在要求提供简明的 reproducer，而不是 AI 生成的冗长说明。

Google 的 Big Sleep 代理去年报告过一批 FFmpeg 漏洞，现在这些漏洞已出现在项目的安全页面上，并标记为 BIGSLEEP。Anthropic 的 Mythos 模型也从 FFmpeg 中挖出一个有 16 年历史的 H.264 缺陷及其他问题，成本约为 10,000 美元；根据其自身说明，其中 3 个已随 FFmpeg 8.1 发布。

几天前，另一个自主工具在 Redis 中发现了一个 authenticated RCE，该漏洞自 7.2.0 版本起就已存在，超过两年无人察觉。相关研究指向相同方向：2 月的一项研究显示，一个 agent 能为 100 个真实 Linux kernel N-day 漏洞中的超过一半复现可用 PoC，效果超过 fuzzing。

对于 FFmpeg，请在上游修复版或发行版的安全更新发布后尽快拉取；并优先处理任何会摄取不受信任 RTSP 或 AV1-over-RTP 的组件。FFmpeg 被广泛捆绑在媒体管线、Python wheels、container images 和 appliances 中，因此不要只停留在系统包；这些嵌入式副本也需要打补丁。

对于 Chrome，请更新到 Linux 上的 149.0.7827.53，或 Windows 和 macOS 上的 149.0.7827.53/54，或者确认自动更新已经完成。

应对节奏也必须随之改变：缩短补丁周期，在可用时启用自动更新，并把包含 CVE 修复的依赖升级视为安全工作，而不是例行维护。

但真正困难的是转变过程。发现这些漏洞已经变得很便宜；而分流报告、发布修复并将其部署到位却没有变便宜。很多工作仍然落在志愿者和少数人工 triager 身上，如今他们还被要求跟上机器的速度。