AI Agent Uncovers 21 Zero-Days in FFmpeg; Chrome Patches Record 429 Bugs
2026/06/06 TheHackerNews — 今週、わずか数日の間に 2 つの出来事が相次いだ。大半の動画関連システムに組み込まれているメディア・ライブラリ FFmpeg において、これまで知られていなかった 21 件の脆弱性を、あるセキュリティ系スタートアップ企業が報告した。これらの脆弱性は、自律型 AI エージェントにより発見されたものである。 その一方で Google は、429 件のセキュリティ・バグに対する修正を含む Chrome 149 をリリースした。これは、単一リリースとして過去最多の脆弱性件数である。
FFmpeg の脆弱性は AI により発見されたものであるが、Chrome の記録的な修正件数は、AI が生成する報告の急増に対応するために、Google が報奨金プログラムを刷新した結果として実現したものである。
このように、それぞれの仕組みは異なるものであるが、両者が直面する圧力は同じである。脆弱性に対処しなければならない人々に対して、AI が従来よりも速いペースで、より多くの脆弱性を突き付けている。
FFmpeg に関する発見は Depthfirst によるものであり、同社の自律型セキュリティ・エージェントが、プロジェクトの約 150万行に及ぶ C 言語コードをスキャンし、再現可能な PoC 入力を伴う 21件の確認済みゼロデイ脆弱性を特定した。同社によると、このスキャンにかかった費用は約 $1,000 である。
これらの複数のバグは 15年から 20年にわたり潜在していたものであり、サービス記述テーブル (SDT) コード内のスタック・オーバーフローの脆弱性に関しては、2003年にまで遡るものであり、23年間にわたり修正されていなかった。
その大半は TS デマルチプレクサから VP9 デコーダに至る、複数コンポーネントのパーサーなどにおけるヒープ／スタック・オーバーフローである。Depthfirst によると、一部には既に CVE 識別子が割り当てられており、同社のレポートには CVE-2026-39210 ～ CVE-2026-39218 の 9 件が記載されている。残りについても、修正は完了しているが CVE は付与されていない。同社は PoC も公開している。
別のニュースとして、Chrome 149 では 429 件の脆弱性が修正された。単一リリースとして過去最多となったが、そのうち 100 件以上は Critical または High の深刻度であり、その多くは解放後メモリ使用 (use-after-free) や入力検証不備に起因するものである。
最も深刻な脆弱性 CVE-2026-10881 (CVSS 9.6) は、ANGLE グラフィックス・エンジンにおける境界外 Read／Write の脆弱性であり、細工されたページによりサンドボックス・エスケープが生じ、ホスト上でのコード実行に至るものである。この脆弱性に対して、Google は $97,000 の報奨金を支払った。
最も深刻度の高いバグの多くは内部で発見されたもので、約 90件の深刻度 High のバグのうち、外部研究者からの報告は 10件に留まっている。22件の深刻なバグのうち、19件は Google 自身により発見された。
Google は、429件の脆弱性を AI と直接結び付けていないが、4月に実施された報奨金制度の抜本的な見直しは重要なシグナルである。AI 生成による報告の急増を受け、AI が大量生成する長文レポートではなく、簡潔な再現手順を求めるものへと制度が変更されている。
Google の Big Sleep エージェントは、2025年に FFmpeg の複数のバグを報告しており、同プロジェクトのセキュリティ・ページで BIGSLEEP タグ付きで公開されている。その一方で、Anthropic の Mythos モデルは、約 $10,000 のコストで FFmpeg の 16年前から存在していた H.264 の脆弱性を含む複数のバグを発見し、そのうち 3件は FFmpeg 8.1 に修正が反映されている。
また、数日前には別の自律型ツールが、Redis のバージョン 7.2.0 以降に存在していた認証済みリモート・コード実行 (RCE) を発見したが、この脆弱性は 2年以上も見逃されていたものである。
同様の傾向は、他の研究でも確認されている。2月に発表されたのは、Linux カーネルのゼロデイ脆弱性 100件の半数以上に対して、AI エージェントが PoC を再現したことだ。それは、従来のファジング手法を上回る成果である。
FFmpeg ユーザーに対して強く推奨されるのは、修正済みのアップストリーム・ビルドまたはディストリビューションのセキュリティ・アップデートが提供され次第、直ちに適用することだ。
特に信頼できない RTSP または AV1-over-RTP を処理するシステムに対しては、優先的に対応する必要がある。FFmpeg はメディア・パイプライン／Python ホイール／コンテナ・イメージ／アプライアンスに広く組み込まれているため、システム・パッケージだけではなく、組み込みコピーも対象にしなければならない。
また、Chrome に対しては、Linux 版 149.0.7827.53、Windows／macOS 版 149.0.7827.53／149.0.7827.54 へ更新が必要である。
この新たな速度に対して、ユーザーも適応しなければならない。パッチ・サイクルの短縮／利用可能な環境での自動更新の活用／CVE 修正を含む依存関係の更新を、単なる日常的なメンテナンスではなく、セキュリティ対応として扱うことが求められる。
バグの発見コストは低下したが、トリアージ／修正プログラムのリリース／適用までのプロセスは依然として高コストである。また、その多くはボランティアや少数のトリアージ担当者に依存していることから、機械の速度に追従することが、人間に対して求められるという、別の課題が生じている。
訳者後書：AI の進化により脆弱性の発見コストが下がりましたが、急増している報告件数への対応が追いつかないという問題が浮上しています。FFmpeg で見つかった CVE-2026-39210 〜 CVE-2026-39218 などのバグや、Chrome 149 で修正された最深刻な CVE-2026-10881 (CVSS 9.6) といった、長年見逃されていた問題が次々と浮き彫りになっています。しかし、バグを見つける機械の速度に対して、それらを精査して修正プログラムを適用する人間のトリアージ体制が追いつかないという大きな問題が生じています。今後は対応プロセスの効率化が、エンジニアに求められていくのでしょう。
IoT OT Security News 
You must be logged in to post a comment.