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まで含めて露出を洗い出すなら、脆弱性診断・セキュリティ診断で外部から届くポートを一覧にすると漏れを防げます。

KEVに載った4件のCVEと連鎖で認証なしRCEに至る仕組みの整理

CISAが10月20日に出したKEV追加のアラートでは、6件のうち4件がPlex Media Serverでした。残る2件のうち1件は国産WAFのSiteGuardで、SiteGuardの脆弱性CVE-2026-106931の確認手順に別途まとめています。

Plex告知とNVD・KEVで食い違う4件の説明を並べた比較表

同じCVE番号でも、Plexの公式フォーラムの告知とNVDの説明では、書かれている中身がずれています。NVDの文面は、CISAが9月23日に公開したアドバイザリVA-26-266-01と同じです。

KEVの名称はCWEの分類名を写したもので、攻撃の中で各CVEが担う役割はPlexの説明のほうが読み取りやすくなっています。社内の報告書にはCVE番号と両方の説明を並べて書くと、後から読む人が混乱しません。なお同じアドバイザリにはCVE-2026-96651（パストラバーサル・6.5）も載っていますが、10月23日時点でKEVには入っていません。修正版は4件と同じ1.43.3.10861です。

単体では中程度の4件が連鎖で認証なしのRCEに至る攻撃の5段階

4件のCVSSは最大でも7.2で、単体で見ると緊急度は高く見えません。危険なのは組み合わせです。発見者が10月16日に公開した技術解説は、次の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の計算式とスコアの目安、自分自身へ要求を出させる攻撃の仕組みはSSRFの仕組みと防御実装で扱っています。

9月1日の修正告知から10月20日のKEV追加までの対応時系列

時系列は、発見者の解説・Plexの告知・NVDの登録日から組み立てました。

修正から悪用まで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'<MediaContainer[^>]*\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サポートの解説で環境ごとに示されています。

# 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日に悪用を観測した研究者のハニーポットの記録では、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やルーターの問い合わせ記録で名前を検索すると見つけやすいです。マイナーが入った後の痕跡の追い方は暗号通貨マイニングマルウェアの検出方法も参考になります。

更新と再構築：Docker版の入れ替えと侵害時にデータを捨てる判断

痕跡が無ければ更新で終わり、あれば作り直します。分かれ目はここだけです。

pms-docker：latest・publicで1.43.3.10861以降へ更新

公式イメージ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の仕組みです。NASのアプリセンター版は、NASの管理画面で更新を当てたうえで同じ確認をします。

侵害の痕跡が出た場合にデータディレクトリを再利用せず作り直す理由

Plexは侵害の疑いがあれば、古いデータディレクトリを使い回さずクリーンインストールから作り直すよう求めています。最低限の手当てとして挙げているのは、Codecsフォルダの中身の削除、Preferences.xmlに覚えのない変換設定が無いかの確認です。加えて、Plexアカウントの全デバイスからのサインアウトとパスワードの変更も求めています。

痕跡が出たサーバーで更新だけを当てるのは誤りです。攻撃者はPlexの実行ユーザーの権限でコードを動かしており、Codecs以外の場所に何を残したかを外から確かめきれません。ライブラリのメタデータは作り直せば戻ります。業務端末と同じネットワークにあった場合は、横への広がりを含めたフォレンジック調査の流れと依頼先の選び方を検討します。

公開範囲の判断：リモートアクセスと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の安全性の解説にまとめました。家族や知人とライブラリを共有しているなど、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の仕組みと発見から修正までの実務を解説：公表から修正までの流れの基礎です。
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVEとNVD・CWEの関係を整理しています。
• NetScalerの脆弱性CVE-2026-88771とは？影響ビルドの確認コマンドと侵害調査の手順：同じく悪用済みの脆弱性で侵害調査まで進める例です。
• リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説：32400番を直接公開しない構成を考える材料です。
• Dockerとは｜仮想マシンとの違い・必要スペック・Desktop/Engineの違いとインストール手順【2026年10月】：Docker版Plexを運用する前提知識です。