ハクソク

世界を動かす技術を、日本語で。

FFmpegにおける21のゼロデイ脆弱性

2026年6月13日原文(depthfirst.com)

概要

  • depthfirst社の自律型セキュリティエージェントがFFmpegで21件のゼロデイ脆弱性を発見
  • GoogleやAnthropicの徹底的な分析を上回るコスト効率（1,000ドルで発見）
  • いくつかの脆弱性は15年以上潜在していた
  • 実証可能なPoC（概念実証）入力を自動生成し、脆弱性を再現・確認
  • FFmpegは世界中で広く利用されるメディア処理ライブラリであり、セキュリティ上極めて重要

depthfirstの自律型セキュリティエージェントによるFFmpegゼロデイ発見

  • depthfirst社 の自律型セキュリティエージェントによるFFmpegのゼロデイ脆弱性発見
  • Googleの Big Sleepチーム やAnthropicの Mythosモデル による先行分析を受けての取り組み
  • エージェントは 具体的なPoC入力 を生成し、机上の理論ではなく実際に再現可能な証拠を提示
  • 発見コストは 約1,000ドル で、Anthropicの10分の1以下
  • 一部の脆弱性は 15～20年 以上も未発見だった事例

FFmpegの重要性と難易度

  • FFmpeg は世界中のブラウザやストリーミング基盤で利用されるメディア処理ライブラリ
  • 約 150万行 に及ぶ最適化されたCコードと、20年以上にわたる手動監査・ファジングの蓄積
  • 近年はAIモデルによる自動解析の進展でバグ発見が困難化
  • セキュリティ上の重要性と ゼロクリック攻撃 の標的となりやすい現状

セキュリティエージェントの特徴

  • コーディングエージェントとは異なり、 脅威モデリング と攻撃経路の特定に特化
  • データフロー解析による 攻撃者制御入力 の追跡と脆弱性箇所の特定
  • 誤検知防止 のためのガードレール（実際に再現可能か、攻撃経路が存在するか等の検証）
  • 必要に応じて テスト用ハーネス を自動生成し、仮説の具体的検証を実施
  • 発見結果は 具体的な入力例 とともに提示し、実用性・即応性を担保

発見された脆弱性の概要

  • 合計 21件のゼロデイ を発見、TSデマルチプレクサやVP9デコーダなど多岐にわたる

  • コストは約 1,000ドル、Anthropicの10分の1

  • 8件 はすでにCVEが割り当て済み

    • CVE-2026-39210: TSデマルチプレクサのヒープバッファオーバーフロー（2010年導入）
    • CVE-2026-39211: swscaleリファクタ時の整数オーバーフロー（2010年導入）
    • CVE-2026-39212: ffmpeg_opt.cの再帰的オプション解析によるスタックオーバーフロー（2025年）
    • CVE-2026-39213: yuv4mpegenc入力経路のヒープバッファオーバーフロー（2023年）
    • CVE-2026-39214: SDT実装時のスタックバッファオーバーフロー（2003年、23年間未発見）
    • CVE-2026-39215: update_mb_info()のヒープバッファオーバーフロー（2012年）
    • CVE-2026-39216: img2enc.cのヒープバッファオーバーフロー（2012年）
    • CVE-2026-39217: VP9デコーダのヒープバッファオーバーフロー（2025年）

  • その他の脆弱性も 詳細な技術ID で管理され、順次修正・CVE申請予定

代表的な脆弱性事例：AV1 RTPデパケタイザのヒープバッファオーバーフロー

  • AV1 RTPデパケタイザ （libavformat/rtpdec_av1.c）でのヒープバッファオーバーフロー

  • ネットワーク経由で到達可能、一般的なffmpegコマンドで発動

  • わずか 183バイト のパケットで任意コード実行の原始的Exploitが可能

  • AV1のOBU（Open Bitstream Unit）分割・再構築処理で、Temporal Delimiter OBUの処理不備が原因

  • pktpos が確保済みバッファを超えて進むことで、バッファ外書き込みが発生

    • コード例: pktpos += obu_size; によるバッファサイズ超過

depthfirstエージェントによる発見の意義

  • 既存のAIモデル （Big Sleep、Mythos）に頼らず、独自のエージェントで新規脆弱性を発見
  • 実行可能なPoC を自動生成し、発見したバグが本当に攻撃可能かまで自動検証
  • コスト効率 と再現性を両立した脆弱性発見手法の実証
  • FFmpegのような大規模・堅牢なOSS に対するAI活用型セキュリティアプローチの有効性を示唆

今後の展望と課題

  • AI/エージェントによる 大規模コードベースの自動セキュリティ監査 の発展可能性
  • 既存モデルの限界突破 と、今後のAIセキュリティ分野への期待
  • OSSプロジェクトへの 自動脆弱性発見・修正支援 の普及促進
  • 深層解析・具体的PoC生成 によるセキュリティ報告の質向上と迅速な対応体制構築

Hackerたちの意見

このバグの影響範囲が深刻な理由だね。攻撃者が影響を与えたRTSP URLをFFmpegに指し示すデプロイメントは、すべて危険にさらされてる。ユーザー提供のストリームURLを取得するメディアインジェストパイプライン、監視カメラやCCTVシステムがRTSPフィードを引っ張ってくるの、リモートAV1-over-RTPソースを処理するトランスコーディングサービスも含まれる。これは実際にかなり深刻だね。公開されることに驚いてるよ。今の時点で、これが悪用されるサービスはいくつか思いつく。

└

深刻な脆弱性を知っているなら、公開することが重要だって言う人もいるかもしれない。そうすれば、脆弱な使い方をしている人たちがリスクを軽減する手段を講じられるから。

└

これを悪用するには、何らかのASLRリークも必要だね。

└

ffmpegはバグやセキュリティレポートに関して、何度も何度も気にしてないって言ってるよ。

俺はFFmpegを個人的にもサービスを作るためにも長いこと使ってる。ファブリス・ベラールは天才だし、ここまで発展させた開発者たちは世界を確実に豊かにしてくれた。でも、信頼できない入力で動かすときにサンドボックス化する価値があるプログラムってFFmpeg以外に思いつかない。すごく複雑な動画や音声コーデックを扱う大量のC言語が使われてるから、完全に正しく動かすのは難しいんだよね。でも、実際にはそれほど大きな問題じゃない。俺はFFmpegをVMやgVisorの中で動かしてるし、最終的にはブラウザで再生するのに全く問題ない動画ファイルができる。ブラウザ内でもさらに別のサンドボックスでデコードされるから、これが難しいんだよ。

└

「ブラウザで再生するのに全く問題ない動画ファイル」ってどういう意味？ブラウザのデコードサンドボックスから逃れられる動画ファイルなんてないって考えるのが普通じゃない？

└

でも、エンコーディングにはハードウェアアクセラレーターが必要なことが多いから、またCを使わなきゃいけないんだよね。

└

著作権を持ってる企業がDRMや「信頼できるプラットフォーム」、規制の取り込みとかを求めることで、ここにいくつかのダメージを与えるだろうなって暗い予想をしてる。

この時点で、破損したフリーポインタが呼ばれ、命令ポインタの制御がこちらに来る。非常に深刻だけど、実際にはこのバグが単独で任意のRCEを達成するわけではないみたい（特にASLRがある場合は）。書き込み可能で実行可能なメモリのページがどこかに存在する必要がある。

└

記事では軽く流されてるけど、構造体の次の変数が関数の最初のパラメータになってるから、system()とかで任意のコードを実行できるんだよね。でも、ASLRを突破するためには他のエクスプロイトも必要だね。

外国のエージェントから自分のコードベースを守るための未来は、セキュリティバグを見つけるエージェントを欺くために、コードベースに微妙にプロンプトインジェクションを隠すことなのかな？FFmpegの攻撃者が人気ツールのRCEを見つけるためにその著者のサービスを使う必要があるなら、FFmpegチームが攻撃者に勝つためには、そういうツールの効率を深さ優先で下げる必要がある。

└

いや…

Hacker Newsで議論の続きを見る