AI Agent 以約1000美元成本，在FFmpeg 發現21項零時差漏洞，含多個已編號CVE；其中一個 AV1 RTP depacketizer 缺陷可經 RTSP 零點擊觸發，影響雲端轉碼、IP Cam 與 IPTV 等外部串流系統。
資安業者 depthfirst 宣稱，其以 AI Agent 深度掃描 FFmpeg 原始碼後，發現了 21 項先前未知的 zero-day 漏洞，總成本約 1000 美元。[1] 其中 9 個已取得 CVE 編號，顯示 AI 已不再只是輔助分類工具，而是能直接參與實際漏洞挖掘與驗證的研究流程。[1]
FFmpeg 是廣泛部署的開源音訊與視訊編碼工具，從瀏覽器相關元件、雲端影音轉碼服務，到大型串流平台基礎架構都可能使用它。[1] 由於它常處理不受信任的媒體內容，加上程式碼量接近 150 萬行、又以 C 語言實作，因此長期被視為高風險攻擊面。[1]
根據公開資料，這 21 項漏洞分布在 TS demuxer 到 VP9 decoder 等多個模組。[1] 其中一個特別值得注意的缺陷位於 FFmpeg AV1 RTP depacketizer，可導致堆積緩衝區溢位並進一步達成 PC Control，攻擊者能引導受害者 CPU 執行惡意指令。[1]
這次事件最重要的訊號，不只是「找到很多漏洞」，而是「找到能被實際利用的漏洞」。depthfirst 強調其分析結果附帶可重現的 PoC，且已透過執行驗證，而非停留在理論報告或模糊警示層級。[1] 這代表 AI Agent 已能在真實程式碼中完成漏洞挖掘與驗證，直接把研究推進到可交付的成果。[1]
已公開資訊指出，已編號的漏洞類型包含 5 個 heap-based buffer overflow、2 個 stack-based buffer overflow，以及 1 個 integer overflow，涵蓋 CVE-2026-39210、CVE-2026-39211、CVE-2026-39212、CVE-2026-39213、CVE-2026-39214、CVE-2026-39215、CVE-2026-39216、CVE-2026-39217、CVE-2026-39218。[1] 這種組合顯示問題並非單一邏輯錯誤，而是多個記憶體安全缺陷在不同解析路徑中重複出現。[1]
其中，CVE-2026-39214 甚至可追溯到 2003 年，意味著某些危險程式路徑在專案演進中長期未被察覺。[1] 另有 CVE-2026-39210 與 CVE-2026-39211 出現在 2010 年，CVE-2026-39215 與 CVE-2026-39216 則可追溯到 2012 年。[1]
最危險的未編號漏洞位於 AV1 RTP depacketizer。依照來源描述，攻擊者只要架設支援 RTSP 的影音伺服器，受害者點選該 RTSP 串流 URL，讓 FFmpeg 處理資料流，即可能觸發漏洞。[1] 這種設計屬於 zero-click 攻擊面，因為受害者不需要下載檔案，也不需要進一步互動。[1]
更棘手的是，觸發攻擊的封包僅約 183 bytes，且可混入正常媒體流量，使防護設備不易以流量型特徵直接攔截。[1] 在實務上，這代表傳統只依賴檔案掃描或靜態規則的防禦方式效果有限，因為攻擊載體就是合法格式的串流封包。[1]
這類漏洞的影響範圍極廣，因為任何會讀取外部網路影音串流、並使用 FFmpeg 作為解析核心的系統，都可能暴露於風險中。[1] 來源特別提到雲端影音轉碼服務、IP Cam 監視器後臺與 IPTV 系統，這些場景的共同點是：它們高度依賴自動化串流處理，且通常直接面向外部資料源。[1]
在雲端環境中，若轉碼服務接受外部提供的 RTSP 串流，攻擊者就可能把惡意資料送入後端處理流程，造成服務端被動觸發漏洞。[1] 在監控與廣播場景中，系統常常需要即時接收來源不明的影音流，因此一旦解析層出現 memory corruption，可能導致服務中斷、程式崩潰，甚至更進一步的控制權劫持。[1]
此外，FFmpeg 的部署面非常廣，從前端應用到大型平台都可能內嵌使用，這使得修補不只是一個軟體升級問題，而是供應鏈盤點問題。[1] 管理者必須確認終端產品是否直接或間接依賴 FFmpeg，否則即便核心套件已修補，衍生服務仍可能保留受影響版本。
由於這批漏洞已完成修補，首要措施是立即確認環境中 FFmpeg 及其衍生元件的版本，並套用官方或供應商提供的更新。[1] 若系統來自套件管理器、映像檔或第三方封裝，也應同步檢查相依元件是否已重新建置。
對於暴露 RTSP 或其他外部串流入口的服務，建議把來源白名單、存取驗證與網路隔離作為基本門檻。[1] 這類漏洞的特性是資料本身可能看起來正常，因此只靠內容辨識不夠，必須從「是否允許外部任意串流輸入」這個角度縮小攻擊面。[1]
在偵測面上，應加強應用層日誌、異常崩潰告警與轉碼失敗監控，特別是與 FFmpeg 解析相關的 service crash、segmentation fault 與不尋常的 CPU 行為。[1] 對高風險業務，建議把媒體解析服務與核心業務系統隔離，避免單一解析缺陷直接擴大為橫向風險。
最後，面對 AI 強化的漏洞研究趨勢，防守方不能只依賴傳統低頻更新節奏，而應把開源元件治理納入例行安全作業。[1] 尤其是像 FFmpeg 這種長期處理非信賴媒體內容的基礎元件，更需要定期盤點、及早更新與驗證修補成效。[1]