FFmpeg の MagicYUVデコーダーに深刻な脆弱性 PixelSmash-CVE-2026-8461|セキュリティとITのニュース-セキュリティ対策Lab

投稿日時: 2026年06月24日更新日時: 2026年06月24日

JFrog Security Researchは2026年6月22日、世界で最も広く使われているメディア処理フレームワーク「FFmpeg」のMagicYUVデコーダーに存在するヒープ領域の境界外書き込み可能な脆弱性「PixelSmash」（CVE-2026-8461）を公開しました。

CVSSスコアは8.8（High）で、細工された50KBの動画ファイル1つを処理させるだけで、JellyfinメディアサーバーおよびNextcloudインスタンスに対するリモートコード実行（RCE）が実証されています。

FFmpegのコアライブラリlibavcodecを使用しているすべてのアプリケーションが影響を受ける可能性があり、Kodi・Emby・OBS Studio・Immich・PhotoPrism・GNOME/KDE/XFCEのサムネイル生成器など、広範なソフトウェアエコシステムに及ぶサプライチェーン型の脆弱性です。FFmpegは6月17日にバージョン8.1.2で修正を提供しており、ただちなるアップグレードが推奨されます。

サマリー

CVE：CVE-2026-8461（PixelSmash）
深刻度：CVSS 8.8（High）
脆弱なコンポーネント：FFmpeg libavcodecのMagicYUVデコーダー
脆弱性の種別：ヒープ領域の境界外書き込み（Heap OOB Write）
影響を受けるファイル形式：AVI・MKV・MOV（MP4は対象外）
発見：JFrog Security Research（Yuval Moravchick氏）、2026年5月13日にFFmpegへ報告
修正バージョン：FFmpeg 8.1.2（2026年6月17日リリース）
RCE実証対象：Jellyfin 10.11.9・Nextcloud（動画プレビュー有効時）
DoS影響確認済み：Kodi・Emby・mpv・OBS Studio・ffmpegthumbnailer（GNOME/KDE/XFCE）・Immich・PhotoPrism・vLLM
RCEの前提条件：ASLR無効、またはFlashSV情報漏洩脆弱性との連鎖
影響なし：Plex（独自ビルドで不要なデコーダーを無効化）・MP4コンテナ
ゼロクリック攻撃：Jellyfinのライブラリ自動スキャン経由で実証済み

1 概要
2 原因
3 攻撃シナリオ ─ ゼロクリックからサーバーサイド自動実行まで
4 Plexがなぜ影響を受けないのか ─ デコーダーの明示的な制限という設計選択
5 EmbyとJellyfinの「サイレントなヒープ破損」という問題
6 情報システム部門が取るべき対応
7 FAQ

概要

2026年6月22日、ソフトウェアサプライチェーンセキュリティ企業JFrogは、FFmpegのMagicYUVデコーダーに存在するヒープ境界外書き込み脆弱性の詳細な技術分析を公開しました。

この脆弱性はJFrog Security Researchのリード研究者Yuval Moravchick氏によって発見され、CVE-2026-8461として追跡されています。JFrogは5月13日にFFmpegのセキュリティチームへ報告し、FFmpegは6月17日にバージョン8.1.2でこの問題を修正しています。

JFrogの研究チームは、この脆弱性がサービス拒否（DoS）にとどまらず、特定の条件下でフルリモートコード実行まで発展することを実証しました。具体的には、JellyfinメディアサーバーとNextcloudの2つの異なるターゲットに対して、50KBの細工されたAVIファイルを1つアップロードするだけでリバースシェルを獲得することに成功しています。Jellyfinの場合は、ライブラリフォルダに細工されたファイルを配置するだけでJellyfinが自動的にffprobeを実行しexploitが発動するため、ユーザーが能動的にファイルを開く操作すら不要な経路が存在します。

FFmpegは事実上あらゆるメディア処理アプリケーションに組み込まれているため、JFrogはこれを単一のコーデックデコーダーのバグが数百ものダウンストリームプロジェクトに伝播するサプライチェーン型の脆弱性として位置づけています。

ターゲット	FFmpegの利用形態	影響
Jellyfin 10.11.9	同梱のjellyfin-ffmpeg 7.1.3	ASLR無効でRCE実証済み（jellyfinサービスユーザーとして任意コード実行）
Nextcloud（動画プレビュー有効時）	システムffmpegをshell経由で呼び出し	ASLR無効でRCE実証済み（www-dataユーザーとして任意コード実行）
Kodi	システムlibavcodecにリンク	クラッシュ
Emby 4.8.11	同梱のemby-ffmpeg 5.1	サイレントなヒープ破損（エラー出力なし、exit 0）
mpv	システムlibavcodecにリンク	SIGABRT
ffmpegthumbnailer（GNOME/KDE/XFCE）	システムlibavcodecにリンク	SIGSEGVでコアダンプ
OBS Studio	システムlibavcodecにリンク	クラッシュ
Immich	システムffmpeg	SIGABRT
PhotoPrism	システムffmpeg	SIGABRT
vLLM（動画入力を処理する場合）	PyAV経由でlibavcodecにバインド	DoS（SIGSEGV、3/3で確認）
Plex	カスタムビルド（MagicYUVを含まない）	影響なし

原因

この脆弱性の根本は、FFmpegのフレームアロケーターとMagicYUVデコーダーの2つのコンポーネントがクロマ平面の行数を計算する際に異なるロジックを使っていることです。

フレームアロケーターはコーデックの高さを32の倍数に切り上げてからクロマ平面のバッファサイズを計算します。一方でデコーダーは、攻撃者が制御できるビットストリームから直接slice_heightの値を読み取ります。slice_heightが奇数の場合、天井丸め（AV_CEIL_RSHIFT）の計算でスライスごとに1行余分に加算されます。複数のスライスにわたってこの余分な行が積み重なると、最終スライスの書き込み先ポインターがクロマ平面のバッファ末尾を1行分超えた位置を指すことになります。

フレームアロケーターが確保するクロマ平面バッファ: 16行
デコーダーが2枚目のスライスを書き込む位置:    16行目（0から数えて）→ バッファ外

問題をさらに悪化させているのは、magicyuv.cのスライス高さ検証ロジックがインターレースモードのコードパスにしか存在しないことです。今回悪用される非インターレースのパスにはアラインメントチェックが一切なく、攻撃者は細工したslice_heightを自由にセットできます。この結果、640バイトの完全な攻撃者制御データがクロマ平面バッファの直後のヒープ領域に書き込まれます。

もう一つのサプライチェーン問題として、MagicYUVデコーダーはテスト済みのすべてのディストリビューション（Ubuntu・Debian・Fedora・Arch・Alpine）のFFmpegパッケージにデフォルトで有効な状態でビルドされているという点があります。JellyfinやNextcloud、mpvといったダウンストリームプロジェクトはこのバグを自分たちで導入したわけではなく、FFmpegへの依存を通じて黙って引き継いでいます。そしてほとんどのプロジェクトは個々のコーデックデコーダーを独立して監査したり緩和策を講じる手段を持っていません。これはサプライチェーン上の脆弱性の典型的な構造です。

攻撃シナリオ ─ ゼロクリックからサーバーサイド自動実行まで

JFrogは複数の攻撃経路を実証・指摘しています。

ユーザーが意識せずにトリガーされる経路として最も一般的なのは、デスクトップのファイルマネージャーによるサムネイル生成です。GNOME・KDE・XFCEはフォルダを閲覧するだけでffmpegthumbnailerを自動的に呼び出すため、悪意のある動画ファイルが含まれたフォルダを開くだけで脆弱性が発動します。ファイルを明示的に再生する操作すら不要です。

最も危険な攻撃経路はトレントダウンロードを利用したものです。JellyfinのライブラリフォルダにqBittorrent等のトレントクライアントが直接ダウンロードを行う設定になっている場合、攻撃者が公開トレントトラッカーに細工した動画（例：一般的な映画に見せかけた50KBのAVIファイル）をアップロードします。トレントが完了するとJellyfinのリアルタイムファイル監視がそのファイルを検出し、自動的にffprobeによるメタデータスキャンを開始します。スキャン中にexploitが発動し、ユーザーが一切操作しなくてもリバースシェルが確立します。Sonarr/Radarrなどの自動ダウンロード管理ツールとJellyfinを組み合わせたよくある構成でも同様の経路が成立します。

NextcloudのMovie Preview機能が有効な場合は、ユーザーがファイルをアップロードするとNextcloudがffmpegでサムネイルを生成する際にexploitが発動します。この場合も攻撃者はNextcloudのwebインターフェース上でファイルをアップロードする権限さえあれば実行でき、サーバーサイドでwww-dataユーザーとして任意コードを実行できます。

Slack・Discord・Telegram・WhatsAppなどのチャットプラットフォームも、サーバーサイドで動画プレビューを生成するためにffmpegを利用しているとされており、テスト対象外ではあるものの影響を受ける可能性があるとJFrogは指摘しています。

Plexがなぜ影響を受けないのか ─ デコーダーの明示的な制限という設計選択

今回JFrogがテストしたすべてのアプリケーションの中で唯一影響を受けなかったのがPlexです。

その理由はシンプルで、PlexはFFmpegをカスタムビルドして不要なデコーダーをすべて無効化し、業務上必要なコーデックだけを明示的に許可リストとして登録しています。MagicYUVはそのリストに含まれていないため、デコーダー自体が存在しない状態になっています。

JFrogはこのアプローチを「観測した中で唯一の効果的な防御策」と評しながらも、「テストしたすべてのプロジェクトの中でこの対策を取っているのはPlexだけだ」と指摘しています。FFmpegのデフォルトビルドにはMagicYUVデコーダーが有効な状態で含まれており、他のほとんどのダウンストリームプロジェクトはそれをそのまま利用しています。

メディア処理や動画ファイルを扱うアプリケーションを内製・採用している組織にとって、Plexのアプローチは参考にすべきセキュリティ設計の方向性です。

EmbyとJellyfinの「サイレントなヒープ破損」という問題

EmbyとJellyfinは悪意のあるファイルを処理する際にエラーを出力せず、exit code 0で終了します。一見すると問題が起きていないように見えますが、ASANでビルドされた環境では同一の640バイトOOB書き込みが確認されており、実際にはヒープが破損しています。

これはクラッシュが発生するよりも深刻な失敗モードです。Jellyfinサーバーが何百もの悪意のあるファイルを処理し続けても、管理者のログにはその形跡が何も残らないからです。エラーも警告も出ないまま、サーバーは静かにヒープ破損を蓄積し続けます。

情報システム部門が取るべき対応

FFmpegを利用しているかどうかを確認します。自組織の環境でFFmpegがインストールされているか、あるいはlibavcodecを使用するアプリケーション（メディアサーバー・動画変換ツール・ファイルサーバーのサムネイル生成機能など）が存在するかを確認してください。

以下のコマンドでMagicYUVデコーダーの有効状態を確認できます。

ffmpeg -decoders 2>/dev/null | grep magicyuv

出力に VFS..D magicyuv が含まれていれば、そのFFmpegビルドは脆弱な状態です。

対処として最も確実なのはFFmpeg 8.1.2以降へのアップグレードです。多くのLinuxディストリビューションではパッケージマネージャーからのアップデートで対応できます。Jellyfinを利用している場合は、Jellyfinが同梱しているffmpegも更新された最新版に移行してください。

即座なアップグレードが難しい場合の暫定対応として、MagicYUVデコーダーを無効化したカスタムビルドを作成する方法があります。

./configure --disable-decoder=magicyuv [その他のビルドフラグ]
make && make install

あるいはJFrogが公開している7行のパッチをlibavcodec/magicyuv.cに適用することでも対処できます。

Nextcloudを運用している場合は、Movie Preview機能の有効状態を確認し、FFmpeg 8.1.2への更新が完了するまでの間は無効化を検討してください。Nextcloudの開発チームは本件を「Nextcodeの外側に存在する問題」として修正対応しない方針を示しています。

AIやMLのワークロードで動画ファイルを処理しているチームについても注意が必要です。vLLMなどのマルチモーダルAI推論フレームワークがPyAV（FFmpegのPythonバインディング）経由でlibavcodecを使用している場合、同様のDoSリスクが存在します。

FAQ

Q. Plexは影響を受けますか？

A. いいえ。PlexはカスタムビルドのFFmpegを使用しており、使用するデコーダーを明示的な許可リストで管理しています。MagicYUVデコーダーはそのリストに含まれていないため、Plexには本脆弱性の影響はありません。

Q. MP4形式の動画ファイルは攻撃に使えますか？

A. いいえ。MagicYUVコーデックはMP4コンテナのレジストリに登録されていないため、MP4ファイルを通じてこの脆弱性を悪用することはできません。攻撃に使用できるファイル形式はAVI・MKV・MOVに限られます。

Q. ASLR が有効なLinux環境であれば安全ですか？

A. ASLRが有効な場合はリモートコード実行には至りませんが、サービス拒否（クラッシュ）は確実に引き起こせます。また、JFrogはFFmpegの別コンポーネント（FlashSVデコーダー）に未修正の情報漏洩バグが存在することを確認しており、将来的に連鎖させてASLR回避→RCEに至る攻撃経路が原理上成立する可能性を指摘しています。いずれにしても早急なアップグレードが必要です。

Q. 影響を受けているかどうかを確認する方法はありますか？

A. FFmpegがインストールされている環境で ffmpeg -decoders 2>/dev/null | grep magicyuv を実行し、VFS..D magicyuv という文字列が出力されればそのビルドは脆弱な状態です。また、JFrogはFFmpeg 8.1.2より前のバージョンかつデフォルトビルドの場合、テストしたすべてのディストリビューション（Ubuntu・Debian・Fedora・Arch・Alpine）でMagicYUVデコーダーが有効であることを確認しています。

出典

当サイト関連記事