「うちは動画配信なんてやっていないので、関係ないですよね」——動画まわりの脆弱性の話をすると、たいていこう返ってきます。ところが調べてみると、採用サイトの動画アップロード機能、社内で使っている会議録画の変換ツール、問い合わせフォームに添付されたファイルのサムネイル生成——どこかで必ず、同じ部品を使っていた、ということが起きます。
2026年7月、セキュリティ研究チームが FFmpeg というソフトウェアに PixelSmash と名付けられた脆弱性を公表しました。CVE-2026-8461、深刻度は CVSS 8.8。細工されたメディアファイルを処理させるだけで、任意のコードを実行される可能性があります。そしてこの欠陥は、16年間そこにありました（InfoQ）。
PixelSmashは「開かなくても危ない」— 条件の緩さが問題
この脆弱性が注目されたのは、成立条件の緩さです。攻撃者が用意した細工済みファイルを、こちらのシステムが処理してしまえば成立します。動画プレイヤーで再生した場合はもちろん、家庭用の動画サーバーで配信した場合、そしてLinux のファイルマネージャがサムネイルを生成しただけでも起きうると報告されています。つまり「開かなければ大丈夫」が通じません。ファイルがそこに置かれ、システムが自動で中身を覗きに行った時点で条件が揃います。
ファイル形式も特殊なものではありません。AVI、MKV、MOV といった、ごく普通に流通しているコンテナが使われます。人気の動画に見せかけて配布する、という古典的な手口がそのまま通用する形です。技術的には MagicYUV というコーデックのデコード処理におけるメモリの書き込み範囲の誤りで、修正版は FFmpeg 8.1.2 として公開されています。
「16年間気づかれなかった」という点も、この件の性質をよく表しています。誰も見ていなかったわけではなく、使われすぎていて誰の担当でもなかったというほうが実態に近い。広く使われている部品ほど、責任の所在が曖昧になるという構造は、以前から繰り返し指摘されてきた通りです。
FFmpegは「資産一覧に載らない部品」
中小企業にとって本当の難所は、修正版を当てることではありません。自社が FFmpeg を使っているかどうかを知ることです。
FFmpeg は、動画や音声を扱うほとんどのソフトウェアが内部で呼び出している基盤的な部品です。自社で「FFmpeg を導入した」と決めた覚えがなくても、次のような経路で入り込んでいます。
| 入り込む経路 | 具体例 |
|---|---|
| 自社開発システムの依存部品 | 動画投稿機能、サムネイル自動生成、音声の文字起こし前処理 |
| 業務で使うアプリケーション | 動画編集ソフト、画面録画ツール、メディアサーバー |
| サーバー上の標準パッケージ | Linux サーバーに最初から入っている、他のパッケージが依存して導入 |
厄介なのは、真ん中と下の段です。自社で入れた覚えがないまま存在しているため、資産一覧にもソフトウェア台帳にも載りません。何が入っているか分からないものは、当然、更新の対象にもなりません。この「見えない部品」の問題は、ソフトウェアサプライチェーン攻撃の中核にある論点です。
今週できる確認と、来月までにやること
まず短期の話です。技術担当者がいるなら、自社サーバーとクライアント端末で FFmpeg の有無とバージョンを確認してもらってください。サーバーであればパッケージ管理の仕組みから一覧を出せます。8.1.2 より前のバージョンが見つかったら、更新の計画を立てる対象です。
技術担当者がいない、あるいはシステムの中身を外部に任せている場合は、保守を頼んでいる相手に一行聞くのが最短です。「自社のシステムで FFmpeg を使っていますか。使っている場合、CVE-2026-8461 の影響と対応方針を教えてください」。これで足ります。相手が調べて答えられるなら健全ですし、質問の意味自体が通じないようなら、それはそれで分かることがあります。
そのうえで、来月までに手をつけたいのが依存部品の一覧を持つことです。自社のシステムが何を使って動いているかのリスト、いわゆる部品表を、納品物の一部として受け取っているでしょうか。多くの場合、受け取っていません。受け取っていなければ、次に同じような脆弱性が出たとき、また同じ調査からやり直すことになります。
新規の発注では、この部品表の提出を要件に入れておくことをお勧めします。受け入れの場面で何を確認すべきかは検収のチェックリストでも扱いましたが、「動くこと」の確認だけで終わらせず、「何でできているか」を残すところまでを納品の範囲に含めるかどうかで、その後の数年が変わります。
もう一段、優先順位の付け方にも触れておきます。FFmpeg が見つかったからといって、すべてを同じ緊急度で扱う必要はありません。判断の軸は「外から来たファイルを処理しているか」です。利用者がアップロードしたファイルや、メールで受け取ったファイルを自動で処理する経路があるなら、攻撃者が細工したファイルを送り込める状態にあるということなので優先度は高い。逆に、社内で作った素材だけを扱う閉じた変換処理なら、リスクの入口が狭いぶん順番は後ろで構いません。一覧を作ったあとは、この一問で並べ替えるだけで対応の優先順位が付きます。
一度きりの対応で終わらせない
PixelSmash は、いま話題になっているから対応する、という性質のものではありません。16年潜んでいた欠陥が見つかったということは、同じように潜んでいるものが他にもあると考えるほうが自然です。実際、AI を使った脆弱性発見の手法が広がったことで、長年見過ごされてきた古いコードの穴が次々と表面化しています。この流れは当面続きます。AI が書いたコードの安全性を誰が見るのかという論点はClaude Code のセキュリティ点検の記事で扱いましたが、AI は書く側だけでなく、探す側でも同じくらい速く動いているということです。
だとすれば、個別の脆弱性ごとに慌てる運用は続きません。「何を使っているかを常に把握している状態」と「重大な脆弱性が出たら誰が判断して当てるかが決まっている状態」、この二つを持つほうが結果的に安く済みます。
今週は FFmpeg を確認する。来月までに部品表を手に入れる。この二段構えで進めるのが現実的な進め方です。
自社のシステムに何が使われているのか把握できていない、脆弱性が出たときに誰も判断できる人がいない——そうした状態の整理から、グリームハブの開発・AI・自動化のご相談で承っています。要件によって進め方は変わるため、個別にお見積りします。お問い合わせからご連絡ください。
