--- title: "Plex Media Server 脆弱性：KEV掲載4件の版確認と侵害調査の手順" url: "https://www.issoh.co.jp/tech/details/18809/" published: 2026-10-23 updated: 2026-10-23 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Plex Media Server 脆弱性：KEV掲載4件の版確認と侵害調査の手順 Plex Media Serverの脆弱性4件が、2026年10月20日に米CISAの悪用済み脆弱性カタログ（KEV）へ追加されました。4件を連鎖させると認証なしでサーバー上のコードを実行でき、10月16日の技術詳細の公開以降、暗号資産のマイナーやプロキシを仕込む攻撃が報告されています。この記事では、出典ごとに食い違うCVEの説明、1.43.3.10861を境にした版の判定方法、Codecsフォルダやプロセスを見る侵害調査のコマンド、Docker版の更新と32400番の公開をやめる判断までを整理しました。内容は2026年10月23日時点の公開情報にもとづきます。 ## まとめ：1.43.3.10861未満は即更新、外部公開していたなら侵害調査まで 影響を受けるのは1.43.3.10861より前のすべての版です。修正版は9月1日に告知されており、新しい修正を待つ段階ではありません。今日のうちに版を確かめ、古ければ上げます。 更新だけで終わらせてよいのは、32400番をインターネットへ転送しておらず、リモートアクセスも使っていなかったサーバーです。外から届く状態で古い版を動かしていたなら、侵害されている前提でCodecsフォルダ・設定ファイル・プロセスを点検します。痕跡が見つかれば、データを流用せず作り直すのがPlex自身の推奨です。社内の検証機や店舗のPCに置かれたPlexまで含めて露出を洗い出すなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で外部から届くポートを一覧にすると漏れを防げます。 ## KEVに載った4件のCVEと連鎖で認証なしRCEに至る仕組みの整理 CISAが10月20日に出した[KEV追加のアラート](https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog)では、6件のうち4件がPlex Media Serverでした。残る2件のうち1件は国産WAFのSiteGuardで、[SiteGuardの脆弱性CVE-2026-106931の確認手順](https://www.issoh.co.jp/tech/details/18382/)に別途まとめています。 ### Plex告知とNVD・KEVで食い違う4件の説明を並べた比較表 同じCVE番号でも、Plexの[公式フォーラムの告知](https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319)とNVDの説明では、書かれている中身がずれています。NVDの文面は、CISAが9月23日に公開したアドバイザリ[VA-26-266-01](https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf%5Ffiles/IT/white/2026/va-26-266-01.json)と同じです。 | CVE | Plex告知の説明 | NVD・KEVの説明 | CVSS v3.1 | KEV期限 | | ----------------------------------------------------------------- | ----------------- | -------------- | --------- | ------ | | [CVE-2026-96652](https://nvd.nist.gov/vuln/detail/CVE-2026-96652) | timelineで認証なしSSRF | 同左（SSRF） | 4.3 | 11月3日 | | [CVE-2026-96654](https://nvd.nist.gov/vuln/detail/CVE-2026-96654) | ループバック経由で内部機能へ | エンコードURIの無害化不備 | 6.5 | 10月23日 | | [CVE-2026-96655](https://nvd.nist.gov/vuln/detail/CVE-2026-96655) | 所有者の管理トークン漏えい | 変換処理経由のSSRF | 4.3 | 11月3日 | | [CVE-2026-96656](https://nvd.nist.gov/vuln/detail/CVE-2026-96656) | Codecsへ任意ファイル書き込み | ファイル名・パスの外部制御 | 7.2 | 10月23日 | KEVの名称はCWEの分類名を写したもので、攻撃の中で各CVEが担う役割はPlexの説明のほうが読み取りやすくなっています。社内の報告書にはCVE番号と両方の説明を並べて書くと、後から読む人が混乱しません。なお同じアドバイザリには[CVE-2026-96651](https://nvd.nist.gov/vuln/detail/CVE-2026-96651)（パストラバーサル・6.5）も載っていますが、10月23日時点でKEVには入っていません。修正版は4件と同じ1.43.3.10861です。 ### 単体では中程度の4件が連鎖で認証なしのRCEに至る攻撃の5段階 4件のCVSSは最大でも7.2で、単体で見ると緊急度は高く見えません。危険なのは組み合わせです。発見者が10月16日に公開した[技術解説](https://zmain.info/blog/plex2shell)は、次の5段階で説明しています。 1. /player/timeline はX-Plex-Tokenヘッダの有無しか見ず、値の正しさを確かめない。登録時のprotocolパラメータを使い、サーバー自身の127.0.0.1へ要求を出させる 2. ループバックから来た要求はトークンなしで内部のエージェント用APIを呼べる。searchOneの識別子が検査されず、内部URLへそのまま埋め込まれる 3. サーバーは127.0.0.1で始まるURLへの通信に所有者の管理トークンを付ける。127.0.0.1で始まり攻撃者のホストに解決される名前を使うと、トークンが外へ送られる 4. 奪ったトークンで設定TranscoderH264Optionsを書き換え、動画の変換を実行させてファイルを書き込ませる 5. 変換プロセスの起動時、Codecsフォルダ内の.soが署名や実行ビットを確かめずに読み込まれ、Plexの実行ユーザーの権限でコードが動く CVSSの数字は「前提となる権限」を個別に評価した結果です。1段目が実質的に認証なしで通るため、連鎖の全体では外部の誰でも最後まで進めます。発見者自身による連鎖全体の評価は9.8です。点数の読み方は[CVSSv3の計算式とスコアの目安](https://www.issoh.co.jp/tech/details/5094/)、自分自身へ要求を出させる攻撃の仕組みは[SSRFの仕組みと防御実装](https://www.issoh.co.jp/tech/details/16362/)で扱っています。 ### 9月1日の修正告知から10月20日のKEV追加までの対応時系列 時系列は、発見者の解説・Plexの告知・NVDの登録日から組み立てました。 | 日付（2026年） | 出来事 | | --------- | ------------------------ | | 7月27日 | 発見者がPlexへ報告 | | 9月1日 | Plexが更新を告知（v1.43.2以前が対象） | | 9月23日 | CVE採番・CISAがアドバイザリ公開 | | 10月16日 | 技術詳細とPoCが公開 | | 10月17日 | 研究者のハニーポットで悪用を観測 | | 10月19日 | Plexが告知を更新し広範な悪用を明記 | | 10月20日 | CISAがKEVへ4件を追加 | 修正から悪用まで6週間以上ありました。それでも被害が出たのは、自宅やNASで動くPlexが自動更新されないまま放置されやすいからです。技術詳細の公開から悪用までは1日でした。公開済みの手順がある以上、未更新のサーバーは探されて当たると考えます。 ## 影響版の確認：identityエンドポイントとパッケージ版で判定する手順 判定の基準は1つで、版が1.43.3.10861以上かどうかです。告知のタイトルには「v1.43.2 and earlier」とありますが、10月19日の更新で1.43.3の初期ビルドも対象と明記されました。1.43.3であってもビルド番号まで見ます。 ### 設定画面・dpkg-query・rpmで1.43.3.10861以上かを見る方法 Plex Webでは「Settings」→「General」に版が表示されます。サーバーにログインできるなら、パッケージ管理から読むほうが確実です。 ``` # Debian・Ubuntu dpkg-query -W -f='${Version}\n' plexmediaserver # RHEL・Fedora系 rpm -q plexmediaserver # OSを問わず、サーバー上でHTTPから読む（version属性を見る） curl -s http://127.0.0.1:32400/identity ``` identityは認証なしでmachineIdentifierと版を返す軽い応答です。NAS版やDocker版でパッケージ管理に触れない場合も、この方法なら同じ形で読めます。 ### 複数台のPlexを/identityの版番号で一括判定するPythonスクリプト 社内や検証環境に複数台あるときは、次のスクリプトにホスト名を並べて渡します。標準ライブラリだけで動き、要更新か取得失敗が1台でもあれば終了コード1を返します。 ``` import re import sys import urllib.request # 2026年10月23日時点の修正版（Plex告知・CISA VA-26-266-01） FIXED = (1, 43, 3, 10861) def check(host): url = f"http://{host}:32400/identity" xml = urllib.request.urlopen(url, timeout=10).read().decode("utf-8") # XML宣言の version="1.0" ではなく MediaContainer 要素の属性を読む ver = re.search(r']*\sversion="([^"]+)"', xml).group(1) nums = re.match(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", ver).groups() cur = tuple(int(x) for x in nums) return ver, ("修正済み" if cur >= FIXED else "要更新") hosts = sys.argv[1:] or ["127.0.0.1"] bad = 0 for h in hosts: try: ver, state = check(h) except Exception as e: print(f"{h}: 取得失敗（{e}）") bad = 1 continue print(f"{h}: {ver} {state}") if state == "要更新": bad = 1 sys.exit(bad) ``` 2026年10月23日に、identityと同じ形の応答を返す模擬サーバーで動かしました。1.43.2.10162と1.43.3.10828は「要更新」、1.43.3.10861・1.43.4・1.44.0は「修正済み」と出て、接続できないホストは「取得失敗」になりました。応答の先頭にあるXML宣言にも version=”1.0″ が入っているため、正規表現はMediaContainer要素の中に絞っています。ここを雑に書くと全台が1.0と読まれ、判定が壊れます。 ## 侵害の痕跡調査：Codecs・Preferences.xml・プロセスと通信の点検 Plexの告知が挙げる痕跡は4種類です。見覚えのないプロセス、Codecsフォルダ内の不明な.soか.dll、proxystream.stへの通信、何も再生していないときの高いCPU使用率です。 ### OSとNAS別のデータディレクトリとCodecsフォルダの位置 点検する2か所（CodecsフォルダとPreferences.xml）は、どちらもデータディレクトリの直下にあります。既定の場所は[Plexサポートの解説](https://support.plex.tv/articles/202915258-where-is-the-plex-media-server-data-directory-located/)で環境ごとに示されています。 ``` # Debian・Ubuntu・Fedora・CentOS /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/ # Windows %LOCALAPPDATA%\Plex Media Server # macOS ~/Library/Application Support/Plex Media Server/ # Synology DSM 7 /volume1/PlexMediaServer/AppData/Plex Media Server # Snap /var/snap/plexmediaserver/common/Library/Application Support ``` Docker版は、コンテナの /config に割り当てたホスト側のディレクトリがデータディレクトリになります。QNAPは機種ごとに場所が変わるため、SSHで getcfg -f /etc/config/qpkg.conf PlexMediaServer Install\_path を実行し、結果の末尾に Library/Plex Media Server を足します。 ### 不明な.soとTranscoderH264Optionsの値を拾う確認コマンド Linuxのパッケージ版を例にします。データディレクトリのパスは表に合わせて読み替えてください。 ``` D="/var/lib/plexmediaserver/Library/Application Support/Plex Media Server" # 1. 変換設定に身に覚えのない値が残っていないか grep -o 'TranscoderH264Options="[^"]*"' "$D/Preferences.xml" # 2. 技術詳細の公開日以降に作られたCodecs内のファイル find "$D/Codecs" -type f \( -name '*.so' -o -name '*.dll' \) \ -newermt 2026-10-16 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' # 3. lib で始まらない名前の .so（読み込み時に名前を確かめていない） find "$D/Codecs" -type f -name '*.so' ! -name 'lib*' ``` 2の結果には、Plexが自動で取得した正規のコーデックも混ざります。日時が更新作業の時刻と一致しないもの、所有者がplex以外のものから確かめます。1が空でも安心はできません。発見者の解説によれば、攻撃に使った設定値は使用後に消されるためです。NVDの説明にあるとおり、TranscoderH264Optionsの値は変換のたびにx264のオプションへそのまま足されます。値が入っていれば、まず外部からの書き換えを疑います。 ### マイナーとプロキシのプロセス名、proxystream.stへの通信の確認 告知には、実際に見つかったプロセス名としてmyawesomeproxy・mylovelyminer・x12345が挙がっています。10月17日に悪用を観測した研究者の[ハニーポットの記録](https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html)では、xmrigとmyawesomeproxyが取得されていました。 ``` # Plexの実行ユーザーで動くプロセスをCPU使用率順に ps -u plex -o pid,ppid,pcpu,etime,comm --sort=-pcpu | head -20 # 告知・観測記録に出てくる名前 pgrep -a -f 'myawesomeproxy|mylovelyminer|x12345|xmrig' # Plexの実行ユーザーが張っている外向きの接続 sudo ss -tnp state established | grep -i plex ``` Plexの変換プロセスは再生中に高いCPUを使うので、使用率だけで判断せず、再生していない時間帯に見ます。proxystream.stへの通信は、社内DNSやルーターの問い合わせ記録で名前を検索すると見つけやすいです。マイナーが入った後の痕跡の追い方は[暗号通貨マイニングマルウェアの検出方法](https://www.issoh.co.jp/tech/details/4064/)も参考になります。 ## 更新と再構築：Docker版の入れ替えと侵害時にデータを捨てる判断 痕跡が無ければ更新で終わり、あれば作り直します。分かれ目はここだけです。 ### pms-docker：latest・publicで1.43.3.10861以降へ更新 公式イメージ[plexinc/pms-docker](https://github.com/plexinc/pms-docker)のREADMEによれば、版番号のタグとlatestのほかに、betaとpublicのタグがあります。betaとpublicはイメージにPlex本体を含まず、起動時に更新を確かめて取得します。latestや版番号のタグは、イメージを取り直さないと版が変わりません。 ``` # compose.yaml のサービス名が plex の場合 docker compose pull plex docker compose up -d plex # 版を確かめる（ホストの32400番に公開している前提） curl -s http://127.0.0.1:32400/identity ``` publicタグを使っているなら、READMEの説明では、コンテナを再起動すれば最新版を取得する仕組みです。いずれの場合も、最後に前章のスクリプトかidentityで1.43.3.10861以上になったことを確かめて作業を閉じます。compose.yamlの書き方を確認する際の参照先は[docker-composeの仕組み](https://www.issoh.co.jp/tech/details/13282/)です。NASのアプリセンター版は、NASの管理画面で更新を当てたうえで同じ確認をします。 ### 侵害の痕跡が出た場合にデータディレクトリを再利用せず作り直す理由 Plexは侵害の疑いがあれば、古いデータディレクトリを使い回さずクリーンインストールから作り直すよう求めています。最低限の手当てとして挙げているのは、Codecsフォルダの中身の削除、Preferences.xmlに覚えのない変換設定が無いかの確認です。加えて、Plexアカウントの全デバイスからのサインアウトとパスワードの変更も求めています。 痕跡が出たサーバーで更新だけを当てるのは誤りです。攻撃者はPlexの実行ユーザーの権限でコードを動かしており、Codecs以外の場所に何を残したかを外から確かめきれません。ライブラリのメタデータは作り直せば戻ります。業務端末と同じネットワークにあった場合は、横への広がりを含めた[フォレンジック調査の流れと依頼先の選び方](https://www.issoh.co.jp/column/details/2812/)を検討します。 ## 公開範囲の判断：リモートアクセスと32400番の直接転送をやめる基準 今回の連鎖は、32400番に外から届くことが出発点です。更新が済んでも、次の脆弱性で同じことが起きる構成は残ります。 ### リモートアクセスの無効化とホスト側ファイアウォールでの32400番の制限 Plexは、リモートアクセスが要らなければ「Settings」→「Remote Access」で無効にし、必要が無ければ32400番の直接転送もやめるよう勧めています。ルーターの転送設定を消したうえで、ホスト側でもLANの外からの接続を断ちます。 ``` # ufw の例：LAN（192.168.1.0/24）からだけ32400番を許可 sudo ufw allow from 192.168.1.0/24 to any port 32400 proto tcp sudo ufw deny 32400/tcp sudo ufw status numbered ``` 外出先から見たい場合も、32400番を開けるより、VPNの内側からだけ届くようにするほうが攻撃面は小さくなります。WireGuardを使うメッシュ型VPNの安全性と既定設定の落とし穴は[Tailscaleの安全性の解説](https://www.issoh.co.jp/tech/details/5403/)にまとめました。家族や知人とライブラリを共有しているなど、32400番を外へ開け続ける理由がある場合だけ、更新の通知を受けて数日で当てる運用を条件に公開を続けます。 ### 社内ネットワークに置かれたPlexを業務資産として棚卸しする判断 Plexは個人向けの製品ですが、店舗の映像配信や社内の研修動画の共有、開発者の検証機として会社のネットワークに置かれている例があります。情シスの資産台帳に載っていないことが多く、自動更新も切られがちです。 判断の基準は単純です。会社のネットワークにあるなら、業務用のサーバーと同じく版と露出を台帳で管理します。管理できない場合は、そのサーバーを撤去する判断が必要です。「個人が勝手に入れたもの」として見て見ぬふりをするのは過剰な楽観で、今回のように認証なしで乗っ取られれば、社内LANへの踏み台になります。 ## Plex Media Serverの脆弱性対応でよくある質問と回答 今回の4件について出てきやすい疑問に、公開されている一次情報の範囲で答えます。 ### リモートアクセスを無効にしていれば更新しなくても大丈夫ですか？ 更新は必要です。外から届かなければ連鎖の入口は狭まりますが、同じLANにいる端末からは32400番に届きます。社内LANや自宅のネットワークに乗っ取られた端末が1台でもあれば、そこから同じ連鎖を実行することが可能です。リモートアクセスの無効化は更新までの時間を稼ぐ手当てで、Plexの告知も更新を第一の対策に挙げています。 ### Plex Passを契約していない無料版も対象ですか？ 対象です。Plexの告知とCISAのアドバイザリは、影響範囲を1.43.3.10861より前のPlex Media Serverとしており、契約の有無で区別していません。4件はサーバーソフト自体の処理の穴です。見るべきは契約の種類ではなく、動いているサーバーの版番号です。 ### Windows版やmacOS版のPlexも影響を受けますか？ Windows版とmacOS版も影響を受ける対象です。修正版の条件はOSを問わず1.43.3.10861以上で、Plexの告知もCodecsフォルダ内の不明なファイルとして.soと.dllの両方を挙げています。Windowsでは %LOCALAPPDATA%\\Plex Media Server 配下のCodecsフォルダを開き、作成日時が新しく見覚えのないDLLが無いかを確かめます。 ### KEVの対応期限は日本の企業にも関係がありますか？ 期限そのものは米国の連邦政府機関に向けたもので、日本の企業に守る義務はありません。ただし期限の長さは、CISAが急ぐ必要があると見た度合いの目安になります。今回はCVE-2026-96654と96656が追加から3日後の10月23日、96652と96655が11月3日でした。民間でも、KEVに載った脆弱性は優先して直す対象として扱うのが通例です。 ### Plexのアカウントのパスワードも変えるべきですか？ 侵害の痕跡が見つかった場合は変えます。Plexは侵害の疑いがあるとき、全デバイスからのサインアウトとパスワードの変更を求めています。連鎖の途中でサーバー所有者の管理トークンが外へ送られるためです。痕跡が無く、外から届かない構成だったなら、更新だけで足ります。 ## 関連記事 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：公表から修正までの流れの基礎です。 - [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：CVEとNVD・CWEの関係を整理しています。 - [NetScalerの脆弱性CVE-2026-88771とは？影響ビルドの確認コマンドと侵害調査の手順](https://www.issoh.co.jp/tech/details/17983/)：同じく悪用済みの脆弱性で侵害調査まで進める例です。 - [リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説](https://www.issoh.co.jp/tech/details/13554/)：32400番を直接公開しない構成を考える材料です。 - [Dockerとは｜仮想マシンとの違い・必要スペック・Desktop/Engineの違いとインストール手順【2026年10月】](https://www.issoh.co.jp/tech/details/6857/)：Docker版Plexを運用する前提知識です。 --- 出典: [Plex Media Server 脆弱性：KEV掲載4件の版確認と侵害調査の手順]()（株式会社一創）