FFmpeg 安全分析：自主代理發現的 21 個零日漏洞
Depthfirst 使用專門的自主安全代理在 FFmpeg 中識別了 21 個零日漏洞。這些發現包括多個關鍵的記憶體損毀問題，其中一些潛伏超過 20 年，並且在 AV1 RTP 解封裝器中展示了遠端程式碼執行 (RCE) 利用原語。
AI 驅動的漏洞發現
Depthfirst 的安全代理與標準程式編寫代理不同，它專注於對抗性輸入與威脅建模，而非功能實作。系統繪製攻擊面、識別暴露的解析器，並追蹤資料流向易受攻擊的匯點。與理論分析不同，該代理產生具體且可重現的概念驗證 (PoC) 輸入，以確認可達性與可利用性。
此方法證明極具成本效益，發現了約 21 個漏洞，花費約 1,000 美元——約為使用其他先進模型（如 Anthropic 的 Mythos）進行類似工作成本的 10%。
已發現漏洞的摘要
這 21 個漏洞遍及各種元件，從 TS 解復用器到 VP9 解碼器。已有八個分配了 CVE，其他則由 Depthfirst 內部追蹤。
已分配 CVE 的漏洞
| CVE | 類型 | 元件 | 說明 |
|---|---|---|---|
| CVE-2026-39210 | 堆緩衝區溢位 | TS 解復用器 | 缺少長度界限檢查；於 2010 年引入。 |
| CVE-2026-39211 | 整數溢位 | swscale | 尺寸因子公式缺少上限；於 2010 年引入。 |
| CVE-2026-39212 | 堆疊溢位 | ffmpeg_opt.c |
遞迴選項解析未設深度限制；2025 年 7 月回歸。 |
| CVE-2026-39213 | 堆緩衝區溢位 | yuv4mpegenc | 缺少對封包大小的尺寸驗證；於 2023 年引入。 |
| CVE-2026-39214 | 堆疊緩衝區溢位 | SDT 實作 | 未能追蹤剩餘空間；自 2003 年起潛伏。 |
| CVE-2026-39215 | 堆緩衝區溢位 | update_mb_info() |
邏輯錯誤導致 12 位元組溢位；於 2012 年引入。 |
| CVE-2026-39216 | 堆緩衝區溢位 | img2enc.c |
無界的尺寸衍生大小；於 2012 年引入。 |
| CVE-2026-39217 | 堆緩衝區溢位 | VP9 解碼器 | 瓦片執行緒緩衝區缺少重新配置；2025 年 3 月回歸。 |
| CVE-2026-39218 | 堆緩衝區溢位 | DASH 解復用器 | 未能拒絕負的持續時間值；於 2017 年引入。 |
其他顯著發現
- DFVULN-127 (Heap Buffer Overflow)： 在 RTP AV1 解封裝器中發現；允許 RCE 原語。
- DFVULN-122 (Heap Buffer Overflow)： 在 RTP MPEG-4 解封裝器中發現；自 2005 年起潛伏。
- DFVULN-123 (Integer Overflow)： 在 RTP LATM 解封裝器中發現；允許讀取超過堆緩衝區約 1 GB 的資料。
- DFVULN-120 (Integer Underflow)： 在 AVI 解復用器中發現；可觸發約 2 GB 的分配，導致拒絕服務 (DoS)。
深入探討：AV1 RTP 解封裝器中的 RCE
其中最關鍵的發現之一是 libavformat/rtpdec_av1.c 中的堆緩衝區溢位。此漏洞可透過標準 RTSP 串流請求 (ffmpeg -i rtsp://attacker/stream) 觸發，無需特殊旗標或使用者互動，只要開啟串流即可。
根本原因
此漏洞出現在對時間分隔符 (TD) OBU 的處理上。解封裝器設計為忽略並移除 TD 標記。然而，程式碼會根據攻擊者指定的 obu_size 前移輸出游標 (pktpos)，卻未透過 av_grow_packet 分配相應的記憶體。
這導致兩個關鍵失敗：
- 受污染的寫入游標：
pktpos被推進，但底層緩衝區未擴大。 - 攻擊者可控內容： 由於輸入指標 (
buf_ptr) 未前移，下一次迭代會將 TD 本身的位元組重新解析為新 OBU，允許攻擊者精確控制在受污染偏移處寫入的內容。
利用路徑
透過仔細調整 obu_size 為 148，攻擊者可使寫入從 pkt->data[148] 開始。由於 FFmpeg 的 64 位元組對齊，AVBuffer 的帳務結構緊接在資料緩衝區之後。AVBuffer.free 函式指標位於偏移 152。
透過構造特定的 OBU 載荷，攻擊者可將 free 指標覆寫為受控位址。當緩衝區隨後被釋放（由第三個偽造的 OBU 強制重新配置觸發）時，FFmpeg 會呼叫已損壞的 free 指標，從而讓攻擊者取得指令指標 (RIP) 的控制權。
社群觀點與安全影響
這些漏洞的發現引發了關於在 C 語言中解析複雜媒體格式固有風險的討論。
需要沙箱化
許多社群成員強調，在處理不可信內容時，FFmpeg 絕不應在未使用沙箱的情況下執行。
"Ffmpeg 絕對不應在未使用沙箱的情況下執行，若你處理任何不可信或使用者提供的內容。我知道有人這樣做，而這些人正承擔不合理的風險。"
專家建議使用虛擬機或類似 gVisor 的工具來隔離此程序，因為媒體編解碼器的複雜性使其幾乎無法徹底安全。
AI 在安全領域的角色
雖然這些發現展示了大型語言模型的威力，但一些批評者認為業界過於專注於報告而非修復。有人呼籲 AI 代理不僅提交錯誤報告，還應產生 pull request (PR) 直接修補漏洞，以減輕開源維護者的負擔。
記憶體安全
這些發現中緩衝區溢位與整數下溢的普遍性凸顯了關於記憶體安全語言的持續討論。部分貢獻者指出，許多此類問題在 Rust 或 Go 等語言中將不存在或易於被捕捉，因為它們對算術溢位與記憶體邊界的處理更為嚴格。
Depthfirst 的自主安全代理在 FFmpeg 中發現了 21 個零日漏洞，其中包括 AV1 RTP 解封裝器中的關鍵 RCE 原語，展示了 AI 在硬化的 C 程式碼中發掘潛在錯誤的能力。
FFmpeg 安全分析：自主代理發現的 21 個零日漏洞