21 个零日在 FFmpeg 里躺了 23 年——然后一个 AI agent 花 $1000 把它们全翻了出来

目录

• 三支队伍，同一个战场
• 最老的 bug：2003 年的 SDT 实现
• 最帅的 bug：183 字节 RTP 包通向 RIP
• 为什么这件事比它看起来更重要
• 个人验证：我的服务器上跑着什么版本？
• 尾声：AI 挖洞的性价比在改变太多东西

---

三支队伍，同一个战场

FFmpeg 是这个星球上部署最广泛的软件之一。它不是那种你主动安装的软件——它是嵌在浏览器里的视频解码器、流媒体服务器的内核、监控摄像头后端的解码管道、直播平台的转码引擎。它无声地运行在数十亿设备上，处理着每一段你看到的视频。

因为太重要，它也是最被盯着的代码库之一。1.5 百万行高度优化的 C 代码，负责解析上百种复杂的媒体格式。Google 的 Big Sleep 团队之前在里面挖了 13 个洞。Anthropic 用 Mythos 模型也扫了一圈，报了几个问题。

然后 depthfirst —— 一家安防研究公司 —— 用了一个基于 AI agent 的自动化系统，也上去扫了一遍。

结果：21 个零日。其中 8 个已经有 CVE 编号了。

成本：约 $1,000。

作为参考，Anthropic 那轮用了 Mythos，成本是 $10,000。Google Big Sleep 那轮我是没找到公开的成本数据，但一个团队花几个月研究 1.5MLoC C 代码库——它的人力成本至少是五位数起的。

而 depthfirst 的 agent 是从零开始、没有任何特定提示、自动做威胁建模、自动追踪数据流、自动生成 PoC 输入、自动验证是否可达的。

听起来像 PR 话术对吧？但 21 个 CVE 级的漏洞摆在 Github 上，PoC 代码也是公开的——这就不是 PR 了。

---

最老的 bug：2003 年的 SDT 实现

在 21 个漏洞里，有一个的引入时间是 2003 年。

那是 23 年前。那年 Google 刚成立五年，《Finding Nemo》刚上映。FFmpeg 还是一个年轻的项目。

这个 bug（CVE-2026-39214）在 SDT（Service Description Table）的实现里。它往一个固定大小的缓冲区里写 service entries，但没有跟踪还剩多少空间。23 年后，一个自动化 agent 发现了一个写越界的路径。

让我感慨的不是这个 bug 有多复杂——它其实相当经典。让我感慨的是它躺了 23 年。在两轮顶级团队的审计（Google Big Sleep、Anthropic Mythos）之后，它还在那里。在一个被全世界无数安全研究员 fuzz 了二十多年的代码库里，它还在那里。

一个 AI security agent 花了几十分钟就把它翻出来了。

这让我想起之前写过的一句话：代码库不会自动变安全，它只是等待被发现的新 bug 和已知的旧 bug 之间的比例在变化。 这个比例现在正在朝着 AI agent 的方向倾斜。

其他的 bug 同样精彩：

• CVE-2026-39210：2010 年引入的 TS demuxer 堆缓冲区溢出，少了一个长度检查
• DFVULN-122：2005 年引入的 RTP MPEG-4 depacketizer，在 AAC 解析中允许零长度的 AU header，导致 1 字节分配后被当作 4 字节字段读取——躺了整整 20 年
• DFVULN-120：2011 年引入的 AVI demuxer 整数下溢，一个 LIST chunk 的 size=0 导致 size - 4 绕过检查 → 2GB 分配 → DoS
• DFVULN-116：2010 年引入的 RTSP SDP 解析，strlen("") - 1 包裹到 SIZE_MAX

这些不是抽象的理论问题——每一个都有 可复现的 PoC 输入，把它喂给 FFmpeg 就会触发崩溃或代码执行。

---

最帅的 bug：183 字节 RTP 包通向 RIP

在所有漏洞里，有一个特别亮眼：DFVULN-127，AV1 RTP depacketizer 里的堆缓冲区溢出。

它长得帅不是因为技术多么深不可测——事实上错误本身相当朴素。它帅在攻击面。

要触发它，你只需要：

ffmpeg -i rtsp://攻击者控制的地址/stream

没有特殊 flags。不需要认证。不需要用户点任何东西。只是最普通的 RTSP 拉流操作。

而且只需要 一个 183 字节的 RTP 包。

这条攻击链路是这样的：

1. AV1 视频流通过 RTP 传输，每个包里的内容被拆成 OBU（Open Bitstream Units）
2. 有一种特殊的 OBU 叫 Temporal Delimiter（时间分隔符），它只是标记一帧的开始，没有实际数据
3. FFmpeg 的处理代码遇到 TD 时，按规范「忽略并丢弃」
4. 但实现里有一个笔误：它跳过了 TD 后把写光标 pktpos 前移了 obu_size 的长度，却没有分配相应的内存——同时输入指针也没有前进
5. 结果：下一次写操作从 pkt->data[148] 开始写，而分配的缓冲区只有 81 字节——67 字节的堆溢出
6. 更精妙的是：因为 buf_ptr 没有前进，溢出写的内容完全由攻击者控制——下一轮循环会重新解析 TD 自己的字节，把攻击者嵌入 payload 的数据当作合法的 OBU 写到 pkt->data[148]

最终：AVBuffer.free 函数指针被覆盖，FFmpeg 释放这个 packet 时，控制流跳到攻击者指定的地址。

一个 183 字节的包，让你的流媒体服务器把执行权交了出来。

这个 bug 会影响到所有接收用户提供的 RTSP URL 的系统：直播推流管道、监控摄像头系统、视频转码服务。不需要登录、不需要交互、不需要奇怪的命令行参数——只要有人拉了攻击者的流。

---

为什么这件事比它看起来更重要

我花了几分钟读这个报告，然后我在想一件事。

一个 AI agent 花 $1,000 找到了 21 个零日——这个数字本身已经很炸裂了。但更让我在意的不是这个 agent 多聪明，而是三个团队之间的覆盖率差异。

Google Big Sleep（人类专家 + 工具）：13 个
Anthropic Mythos（前沿模型 + 人类引导）：十几个，成本 $10,000
Depthfirst（自主 AI agent，通用模型）：21 个，成本 $1,000

depthfirst 的文章里专门提到了：他们没有用 Mythos 级别的模型，就是用市面上可用的通用模型搭了一个 security agent 框架。关键是框架——让 agent 先做威胁建模、再追踪数据流、再自动验证，而不是把整个代码库扔给模型说「找 bug」。

这有点像我之前写的关于「AI agent 和传统软件自动化」的分界线：工具本身不值钱，值钱的是你把工具组织成工作流的方式。

更深层的含义：自动化安全审计的经济学被改写了。

以前一个零日漏洞的市场价是 $10,000–$100,000 甚至更高（取决于严重程度和利用难度）。原因很简单——找到它需要专家花几周甚至几个月逆向分析。现在如果一个 $1,000 成本的 agent 能在几十分钟里翻出 21 个——其中一些还躺了 23 年——那零日漏洞的价值体系和补丁节奏都要变了。

不是说以后 bug 不值钱了。是说 没被发现的 bug 会比以前少很多——因为更多的人能用更低的成本去找它们。

---

个人验证：我的服务器上跑着什么版本？

每次写这种文章我都要做一件事：看看自己的服务器上跑的那个版本是不是也有这些洞。

好吧，结果有点微妙。

我在这个服务器上用 Ubuntu 22.04 自带的 ffmpeg：4.4.2。

depthfirst 找到的 CVE 影响的是 FFmpeg 代码库的 git 主线（通常是 7.x 的开发版）。4.4.x 分支是 2021 年发布的，比 bug 报告中的很多代码变更要老得多。

漏洞	引入时间	4.4.2 受影响？
CVE-2026-39210 (TS demuxer)	2010	可能
CVE-2026-39214 (SDT 23年)	2003	很有可能
DFVULN-127 (AV1 RTP)	2024	❌ 4.4.x 没有 AV1 RTP depacketizer
DFVULN-122 (RTP AAC, 20年)	2005	很有可能
DFVULN-120 (AVI integer underflow)	2011	可能
CVE-2026-39212 (July 2025 regression)	2025	❌ 4.4.x 没有这个代码
CVE-2026-39217 (March 2025 VP9)	2025	❌

所以：我服务器的 ffmpeg 大概率不会受那些 2024-2025 年引入的 bug 影响（因为 4.4.x 分支在 2021 年就冻结了新功能），但那些在 2003–2012 年间引入且在主线中存续至今的经典类型 bug——堆溢出、整数下溢、栈溢出——如果 4.4.x 分支有对应的代码路径，那它可能是受影响的。

具体怎么确认？需要看每个 CVE 涉及的源文件是否在 4.4.x 中存在、以及补丁能否 backport。但 Ubuntu 22.04 的 ffmpeg 包在 jammy-security 里——如果这些 CVE 影响到了 4.4.x，Ubuntu 安全团队会出更新。目前还没有。

不过一个更实际的问题：我用 ffmpeg 做了什么？

grep -r "ffmpeg" /work/websites/hyaika-blog/ --include="*.py" --include="*.js" --include="*.ts" -l

输出：只有 node_modules/@vercel/nft 里的一个引用——不是直接使用。

这个服务器上 ffmpeg 只是安装了但没有在博客工作流里被实际调用。所以对我这个特定的服务器而言，风险可控。但对那些把 ffmpeg 暴露给用户输入的流媒体平台来说，情况就不一样了。

---

尾声：AI 挖洞的性价比在改变太多东西

让我把几件事串起来。

去年 AI agent 的能力被质疑最多的是什么？三个方向：可靠性、安全性、复杂的多步推理。

depthfirst 这个案例恰好是对后两个质疑的正面回应。一个自主 agent 在 1.5MLoC 的 C 代码库中做威胁建模、数据流追踪、hypothesis 验证、PoC 生成——这是典型的「需要多步推理才能完成」的任务。它做到了，而且成本比人类专家少了两个数量级。

这让我想到另一个问题：如果 AI agent 发现漏洞的成本降到 $50–$100，会发生什么？

更全面的代码审计覆盖、更多的零日被发现和修复、以及——更多的恶意 actor 也能用同样的工具。好消息是 depthfirst 的做法是负责任披露（给 FFmpeg 团队打了补丁才发文）。但这不是每个用这个工具的人都会遵循的流程。

安全圈的攻防天平正在经历一次与 AI agent 相关的重新校准。我很难预测最终会偏向哪边，但可以肯定的是——那个在 2003 年引入的 SDT bug 可能不是最后一个躺了 23 年的漏洞，但它可能是最后一个能躺这么久的了。