Plex Media Serverの連鎖攻撃が広く悪用！更新と侵害確認を急ぐ理由

Plex Media Serverをインターネットへ公開している運営者は、バージョン確認だけでなく侵害の有無まで点検する必要があります。Plexは2026年10月19日、4件の脆弱性が連鎖すると未認証の遠隔攻撃者がPlex Media Serverのプロセス権限でコードを実行できると説明し、インターネット公開サーバーへの広範な攻撃を確認したと追記しました。

米国CISAも10月20日にCVE-2026-96652、CVE-2026-96654、CVE-2026-96655、CVE-2026-96656を既知の悪用脆弱性カタログへ追加しました。本稿は10月21日にPlexの告知とCISAの構造化アドバイザリを照合したニュースです。4件は9月23日に公表済みですが、悪用の広がりとCISAへの追加が新しい事実です。公表日、悪用状況の更新日、記事の確認日を混同しません。

一次資料：Plex：Plex Media Server 1.43.2以前に関する重要なセキュリティ更新
一次資料：CISA：Plex Media Server CSAFアドバイザリ VA-26-266-01

対象は1.43.3.10861より前のPlex Media Server

CISAのCSAFアドバイザリは、Plex Media Server 1.43.3.10861より前を影響対象とし、1.43.3.10861で修正済みとしています。Plexも1.43.3.10861以降は今回の4件の影響を受けないと説明しています。単に画面へ「1.43.3」と表示されるかではなく、ビルド番号まで確認してください。

Plexは9月1日の最初の告知で、Plex Media Server 1.43.3とPlex Desktop 1.115.0への更新を案内していました。その後、10月19日にCVEの詳細、連鎖による影響、実際の悪用状況を追記しています。最初のメールや告知を見て更新したつもりでも、実機が修正版へ到達しているかを再確認することが重要です。

NASではメーカーのパッケージ管理画面に最新ビルドが反映されるまで時間差が生じることがあります。Plexは適切なパッケージを手動で導入する方法も案内しています。Dockerではタグ名だけで判断せず、稼働中コンテナ内のバージョンと、再作成に使うイメージが更新済みかを確認します。更新ファイルを取得しただけで、古いプロセスが動き続けていないかも確かめます。

4件は単独の点数より連鎖を重く見る

CISAのCSAFでは、CVE-2026-96652はplayer timeline経由のSSRFでCVSS 3.1の4.3、CVE-2026-96654はURL値の処理を通じて別のプラグイン機能を呼び出せる問題で6.5、CVE-2026-96655は任意の内部・外部アドレスへ要求できるSSRFで4.3、CVE-2026-96656は任意ファイル書き込みにつながる問題で7.2と評価されています。

個々の点数だけを見ると、すべてがCriticalではありません。しかしPlexは、最初の未認証SSRF、ループバック側の内部機能への到達、管理トークンの取得、Codecsディレクトリへのファイル書き込みが連鎖し、未認証の遠隔コード実行に至り得ると説明しています。脆弱性管理では、同じ製品内で境界をまたぐ組み合わせを別々の低い優先度へ分解しないことが大切です。

Plexの要約とCISAの各CVE記述は、攻撃連鎖のどの段階に焦点を当てるかが一部異なります。本稿では、公開された攻撃コードの具体的な手順やパラメーターを再現しません。運営者が必要とするのは、影響バージョンを特定し、公開範囲を狭め、更新後も侵害の痕跡を調べることです。

Plexが確認した悪用と被害の例

Plexによると、公開PoCは10月16日に出され、その後インターネットへ露出した未更新サーバーに対する広範な攻撃が確認されました。侵害されたサーバーでは暗号資産マイナーやプロキシソフトウェアが動かされ、第三者の通信を被害者の回線から中継する事例があると説明しています。

Plexは、1.43.3.10861より前でインターネットから到達可能なサーバーについて、侵害された可能性を前提に扱うよう勧告しています。これは、更新後に管理画面が正常に表示されたことだけでは、更新前に置かれたファイルや取得された認証情報を否定できないためです。

確認対象として、Plex Media Serverから起動された見覚えのないプロセス、Codecsフォルダー内の不審な.soまたは.dll、proxystream.stへの外向き通信、再生していないのに続く高いCPU使用率が挙げられています。プロセス名の例も示されていますが、名前が一致しないから安全とは限りません。攻撃者が別名を使えるため、親プロセス、配置場所、開始時刻、外部接続を組み合わせて判断します。

最初にバージョンと公開経路を棚卸しする

実務では、Plex WebのSettingsからGeneralを開き、表示されたバージョンを記録します。次に、ルーターのポート転送、クラウドのセキュリティグループ、リバースプロキシ、VPNやトンネル、IPv6の受信規則を確認します。PlexのRemote Accessが無効でも、別の経路でポート32400や管理画面へ到達できる場合があります。

家庭や小規模オフィスのNASは、動画保管だけでなくバックアップ、写真、共有フォルダーを同じ装置で扱っていることがあります。Plexのサービスアカウントが読めるマウント先、同じホストに置いた設定ファイル、環境変数や資格情報を一覧にします。Plexも、サービスアカウントから到達できた共有領域や同じマシンまたは仮想マシン上の認証情報を、潜在的な影響範囲として扱うよう案内しています。

インターネットへ公開していない環境も、更新不要とは限りません。内部の端末や別サービスが侵害された場合の到達経路、誤って再有効化されるポート転送、管理者アカウントの共有を考えると、修正版への更新は必要です。ただし今回のPlex告知が特に強い対応を求めているのは、旧版をインターネットへ公開していた環境です。

遮断と記録を先に行いクリーン再構築を判断する

旧版が公開されていた場合は、まずRemote Accessやポート転送など外部からの到達経路を止めます。可能であれば、停止や再起動の前に現在時刻、稼働プロセス、ネットワーク接続、Codecsフォルダーの一覧、Plexのバージョン、コンテナやサービスの起動設定を記録します。これは本サイトの一般的な提案であり、組織のインシデント対応手順や専門担当の指示がある場合はそちらを優先してください。

更新だけで安全な状態へ戻ったと断定しないでください。Plexは侵害兆候が見つかった場合、または侵害を否定できない場合、古いPlexデータディレクトリを再利用せずクリーンインストールから再構築するよう案内しています。最低限の対応としてCodecsフォルダーを削除し、Preferences.xmlに自分で設定していないトランスコーダー項目がないかを確認する説明もあります。

クリーン再構築では、実行ファイルだけでなく永続ボリュームや自動起動設定も確認します。Dockerコンテナを新しくしても、侵害時のデータディレクトリをそのままマウントすれば問題を持ち越す可能性があります。反対に、調査前にすべてを削除すると攻撃時刻や影響範囲を確かめる材料を失います。保全用の複製と復旧用の新環境を分けて進めます。

Plexアカウントと周辺の認証情報も更新する

Plexは侵害が疑われる場合、すべての端末からサインアウトし、Plexのパスワードを変更するよう案内しています。パスワード変更は、信頼できる端末と回線から行います。同じパスワードを別サービスでも使っている場合は、使い回し先も個別の強いパスワードへ変更します。

サーバー内にAPIキー、共有ストレージの資格情報、バックアップ先の鍵などがあった場合は、ファイルを削除するだけでなく発行元で失効と再発行を検討します。どの秘密が読み取られたか断定できないときは、Plexプロセスの権限で読めた範囲から優先順位を付けます。変更後の値を、調査対象だった旧サーバーへ再投入しないことも重要です。

更新後の検証を成功画面だけで終わらせない

復旧後は、ビルド番号が1.43.3.10861以降であること、外部公開が意図した方式だけであること、見覚えのないプロセスや通信が再発していないことを確認します。動画再生、ライブラリ更新、トランスコードなど必要な機能を段階的に試し、異常なCPU使用率や外向き通信を監視します。

NASや家庭内サーバーでも、管理画面を外部へ直接公開せず、必要な場合は接続元制限やVPNなどを検討します。Plexは遠隔利用が不要ならRemote Accessを無効にし、必要がなければポート32400を直接転送しないよう案内しています。公開を継続する場合も、ルーター設定とPlex設定の両方を定期的に照合します。

監視では「警告が出なかった」ことと「記録がなかった」ことを分けます。更新前のログやプロセス情報を保存していなければ、侵害がなかったと証明できるわけではありません。不明な点が残る場合は、影響を受けた装置だけでなく同じ資格情報や共有領域を使う機器まで調査範囲を広げます。

Web運営者がこの連鎖から学べること

今回の問題は、メディアサーバー固有の更新にとどまりません。外部入力を使うURL取得、ループバックを信頼した内部機能、強い管理トークン、書き込み可能な実行領域が一つの製品内でつながると、個別には中程度の問題でも大きな侵害へ発展します。WebアプリやAIエージェントでも、SSRF対策、内部APIの認証、最小権限、実行可能ディレクトリへの書き込み制限を別々ではなく経路として検証する必要があります。

脆弱性管理台帳にはCVEごとの点数だけでなく、同じ製品、同じ公開面、同じ権限境界に属するかを記録します。悪用確認、公開PoC、インターネット露出、修正版の有無を重ねて優先順位を付ければ、点数順だけでは見落とす連鎖を早く扱えます。

Plex Media Serverを運用している場合は、まず1.43.3.10861以降への更新を確認してください。旧版を外部公開していたなら、更新完了をゴールにせず、侵害兆候、認証情報、共有領域、公開経路を確認します。被害を断定する必要はありませんが、Plexが示した前提に従い、否定できない状態を安全な状態へ戻す作業として進めることが重要です。