AI 安全智能体在 FFmpeg 找到 21 个零日：真正变化是 PoC 成本降到约 1000 美元

depthfirst 6 月 2 日发布研究称，其生产级自主安全智能体在 FFmpeg 中发现 21 个零日漏洞。

其中 8 个已分配 CVE。漏洞覆盖 TS demuxer、swscale、VP9、RTP/RTSP/RTMP、DASH、CAF、AVI 等组件。该公司还称，整个发现成本约 1000 美元。

最值得盯住的不是“AI 又找到了漏洞”。这句话已经听得太多。

真正有意思的是：它不只给出“这里可能有问题”的报告，还生成可复现输入，用 PoC 验证部分漏洞确实可达。代表性案例是 AV1 RTP depacketizer 堆溢出，按 depthfirst 描述，可经普通 RTSP 拉流路径触发，并被证明具备 RCE 利用原语。

这事如果成立，安全审计的门槛会变低。不是低一点，是从“少数团队能长期投入”变成“更多团队可以周期性跑起来”。

FFmpeg 为什么还是硬靶子

FFmpeg 约 150 万行 C 代码。它不只是一个播放器里的库，也常被放进转码、截图、流媒体、内容审核和后端处理管线。

难点在入口太多。

一个漏洞可能来自本地媒体文件，也可能来自 RTSP 拉流、DASH 分片、RTP 包，或者某个老格式的解析路径。多媒体代码还有一个麻烦：历史包袱重，格式边角多，很多解析逻辑是多年累积出来的。

这也是 FFmpeg 的安全价值所在。它长期经受模糊测试、人工审计和大厂安全团队扫描。Google Big Sleep 此前披露过 13 个 FFmpeg 漏洞，Anthropic 也用 Mythos 扫描并发现过问题。

depthfirst 的说法不是证明前两者失败。更准确的判断是：在一个已经被反复翻过的代码库里，自动化系统仍然声称找到了新问题。

这个差别不小。

我更在意的是成本。

如果一个系统能在约 1000 美元级别，对 FFmpeg 这种目标产出高质量漏洞线索，那么它对安全团队的意义就不是“省几个小时读代码”。它开始接近审计预算表里的真实变量。

从报告到 PoC，才是这次的关键

depthfirst 强调，其系统会追踪攻击者输入，判断路径是否可达，并生成具体输入触发漏洞。

这比一份“疑似越界”的报告更有用。漏洞响应团队最怕的不是没有告警，而是告警太多、置信度太低、复现成本太高。

能复现，流程就变了。

安全研究员可以把时间更多放在影响判断、补丁验证和披露协调上。漏洞响应团队可以更快完成定级、回归测试和资产排查。基础软件维护者则要准备面对更多“带 PoC 的报告”，而不是只处理模糊描述。

对依赖 FFmpeg 的多媒体基础设施维护者，动作也更具体：

• 跟进 FFmpeg 上游修复和后续 CVE 分配，不要只看最早那 8 个 CVE。
• 排查是否开放 RTSP/RTMP 拉流、用户上传转码、自动缩略图生成、内容审核等入口。
• 对后端自动处理陌生媒体的服务，优先做隔离、限权和队列降级。
• 如果内部已有 fuzzing 或 SAST 流程，可以评估是否引入能生成可复现输入的 agent，而不是只增加静态告警源。

普通用户偶尔播放一个文件，风险判断要看具体版本和触发路径。真正压力更大的，是把 FFmpeg 放进无人值守流水线的服务端系统。

这一类系统每天自动吃进陌生媒体文件。它不挑来源，也不等人工确认。漏洞一旦命中，影响面会比桌面播放器更难收住。

能力边界要说清：不是 21 个都能 RCE

这里需要降一档判断强度。

目前材料主要来自 depthfirst 自述。21 个漏洞不能直接等同于全部经过独立第三方完整验证。已分配 CVE 的是其中 8 个，也不能推成 21 个都已有编号。

RCE 也一样。

材料支撑的是：一个 AV1 RTP depacketizer 堆溢出案例展示了 RCE 利用原语。它不能外推为所有 21 个漏洞都能远程代码执行。

PoC 能触发漏洞，也不代表每个部署场景都有相同攻击面。不同编译选项、调用方式、协议入口、沙箱隔离和权限配置，都会改变风险等级。

所以这件事的合理结论不是“AI 已经接管漏洞研究”。更稳的说法是：AI 安全智能体正在从辅助审计，逼近低成本发现并验证真实漏洞的阶段。

接下来不该泛泛地说“继续观察”。要看三个硬变量：

如果它只在 FFmpeg 上跑出好结果，那是一次有价值的案例。

如果它能跨多个高价值 C/C++ 项目稳定产出可复现 PoC，基础软件审计的预算模型就会被迫重算。维护者要面对更多高质量报告，攻击者也可能拿到更低成本的挖洞工具。

利器不分善恶。区别只在谁先把它接进流程，谁还在等人工慢慢翻代码。