【ITニュース解説】Detecting CVE-2026-96655 exploitation in Plex logs

Plex Media Serverのセキュリティ脆弱性であるCVE-2026-96655は、メディアコンテンツを管理・配信するサーバーが抱える重大な弱点を示す事例だ。この脆弱性は、SSRF（Server Side Request Forgery）と呼ばれる種類のもので、悪意あるユーザーがサーバーをだまして、本来アクセスすべきではない外部や内部のシステムにリクエストを送らせることを可能にする。Plex Media Serverのバージョン1.43.3.10861へのアップデートでこの弱点は修正されるが、パッチを適用しただけでは、既に誰かがこの脆弱性を悪用したかどうかは分からない。そのため、過去の悪用を検出する方法を知ることは、セキュリティ対策において極めて重要である。

この脆弱性は、Plex Media Serverの/video/:/transcode/universalという特定のエンドポイントに、認証済みのユーザーが細工された情報を与えることで発動する。この情報は「パスパラメータ」と呼ばれ、ユーザーはここに、サーバーにアクセスさせたい任意のURLを巧妙に含ませることができる。サーバーは、そのURLにユーザーの代わりに接続し、得られた情報を処理してしまう。本来、このエンドポイントは動画の形式変換のために使われるが、悪用されると、サーバーは攻撃者の意図するウェブサイトや、通常は外部からアクセスできない内部ネットワークの管理画面などに接続してしまう危険がある。

このような悪用があったかどうかを検出するためには、主に三つの観測点からサーバーの挙動を監視する必要がある。

第一の観測点は「リクエスト自体」の異常である。Plex Media Serverは、動画のトランスコード活動に関するログを記録しており、このユニバーサル・トランスコーダーのエンドポイントへのリクエストも含まれる。ログには、どのクライアントからリクエストがあったかといった情報が残される。一般的な使用であれば、このエンドポイントへのアクセスは、限られたデバイスから、決まった時間帯に行われるのが普通だろう。もし、普段は閲覧だけのデバイスからトランスコードのエンドポイントが呼び出されたり、通常とは異なる形式のパラメータが使われたりした場合は、異常な兆候とみなすべきである。このような異常を検出するためには、まず、サーバーが正常に稼働している「静かな一週間」のログを収集し、通常の通信パターン（ベースライン）を確立することが重要だ。そのベースラインから逸脱した活動がないか定期的にレビューすることで、悪用を早期に発見できる可能性が高まる。セキュリティ侵害を検出してからベースラインを構築しようとしても手遅れなので、これは日常的な運用作業に含めるべきだ。

第二の観測点は「アウトバウンド接続先」、つまりPlexサーバーが外部に接続しようとした先の異常である。これは、アプリケーションのログよりもさらに強力な検出信号となりうる。Plex Media Serverは通常、動画のアートワーク、字幕、メタデータなどをインターネットから取得するために外部に接続するが、内部の管理用ポート、ルーターの管理インターフェース、あるいはクラウド環境で利用される特別なリンクローカルアドレス（例えば169.254.169.254）などに突然接続を開始することは、メディアサーバーとしては全く正当な理由がない。もしファイアウォールやルーター、クラウドのVPC（Virtual Private Cloud）からネットワークのフローログ（通信記録）を取得できる環境であれば、Plexホストから内部の管理サブネットに向けたトラフィックがないかを確認するとよい。単一のホスト上で詳細なネットワーク通信記録（テレメトリ）がない場合でも、ホストレベルのツール、例えば接続監査機能や、一時的なパケットキャプチャを実行することで、不審な通信先を特定できる可能性がある。

第三の観測点は「レスポンス処理の異常」である。不正に細工されたリクエストが成功し、Plexサーバーが予期しないコンテンツを受け取ると、多くの場合、トランスコーダーはそれをうまく処理できずにエラーを発生させる。例えば、コンテンツの解析エラー、異常なメディアプローブの失敗、またはトランスコードセッションが開始された直後に停止するといった現象が見られる。ユーザーからの苦情がないにもかかわらず、トランスコードの失敗が急増している場合は、不審な活動が行われている兆候として調査に値する。ただし、この信号は単独では弱いものであり、悪用の確固たる証拠とみなすべきではない。これはあくまで調査を開始するためのきっかけであり、結論ではないことを理解しておく必要がある。

悪用検出のための準備として、CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、連邦政府機関に対しこの脆弱性に対応するよう指示しており、同様に既知の悪用された脆弱性（KEV）リストに基づき優先順位を付ける組織もこの期限を参考にできる。内部でセキュリティチケットを作成する際は、バージョン1.43.2以前のPlex Media Serverが稼働しているホストのリスト、前述のログフィールドの参照、そして「悪用された証拠がない」とは具体的にどのような状態を指すのかを明確に定義することが求められる。インターネットに公開されているPlex Media Serverの数は膨大だが、この特定のCVEに対する脆弱なアセットが検索ツールでインデックスされていない場合がある。これは、脆弱なサーバーが存在しないことを意味するわけではないため、注意が必要である。

もし、これらの観測点から悪用の証拠が発見された場合、迅速かつ慎重な対応が求められる。まず、関連するログセグメントと接続記録を保全し、他のログが上書きされないようにする。次に、不正なリクエストを実行したアカウントを特定し、そのアカウントを無効化する。不正なリクエストがどのような情報に到達したのかを詳細に確認することが重要だ。例えば、ルーターの管理画面からのレスポンスと、認証情報を含むメタデータサービスからのレスポンスでは、情報漏洩のリスクが大きく異なる。もし標的とされたシステムから何らかの資格情報やトークンが漏洩した可能性がある場合は、直ちにそれらをすべて新しいものに変更する必要がある。これらの対応と並行して、脆弱性を修正するパッチを適用することが最も重要である。なぜなら、検出と封じ込めだけでは脆弱性自体は残ったままであり、再度悪用される可能性があるからだ。悪用を検出するためのルールが一度も発動しなかったとしても、それは安全であるという証明にはならない。パッチの展開が完了するまでの間、そのルールを継続的に実行し、監視を続けることが重要である。