Tautulliの脆弱性、安全な最低バージョンはv2.17.2 非公開でも危険

2026年8月17日時点で、Tautulli（タウチュリー）の安全な最低バージョンは v2.17.2 です。この記事は当初「v2.17.1へ更新を」と案内していましたが、その案内はいま誤りになっています。2026年6月16日に公開されたv2.17.2が、「v2.17.1以下」を対象とする4件の脆弱性を追加で修正しています。つまり、v2.17.1で止めている環境には既知の穴が4件残ったままです。

いま動いているバージョンは、Tautulliの画面で Settings → Help & Info を開けば確認できます。ここに表示された番号が v2.17.2 より小さければ、更新が必要です。Dockerで動かしている場合はイメージを取り直してコンテナを作り直します。イメージを pull しただけでは、動いているコンテナは古いままです。

# docker compose で動かしている場合
docker compose pull
docker compose up -d

# docker run で動かしている場合（LinuxServer 版）
docker pull linuxserver/tautulli:latest
docker stop tautulli
docker rm tautulli
# 同じオプションで docker run をやり直す（設定は -v で指定した保存先に残ります）

# 公式イメージの場合も手順は同じ
docker pull tautulli/tautulli:latest

Windowsやmacos、Linuxに直接入れている場合は、アプリ内の更新機能か GitHubのリリースページから v2.17.2 を取得してください。手順はここまでで足ります。以下は、なぜそれが要るのか、そして「外に公開していないから関係ない」がなぜ成り立たないのかの説明です。

今すぐやるべきこと

やることは1つ、v2.17.2 への更新です。v2.17.1で塞がれた5件と、v2.17.2で塞がれた4件、合わせて9件がこれで片付きます。加えて v2.17.2 は、v2.17.1 で新しく入った X-Api-Key ヘッダーのチェック処理がサーバーをクラッシュさせる不具合も直しています。セキュリティ以外の理由でも、v2.17.1 に留まる利点はありません。

Dockerイメージは、コミュニティで最も使われている linuxserver/tautulli と、開発元が出している tautulli/tautulli の2系統があります。どちらも latest タグを取り直してコンテナを作り直せば最新版になります。NAS（Synology・QNAPなど）のコンテナ管理画面から動かしている場合は、イメージのダウンロードを実行したうえで、コンテナの停止・削除・再作成、またはNAS側の「再起動して更新」に相当する操作が必要です。設定とデータベースはボリュームに残るため、作り直しても視聴履歴は失われません。

更新後、心配であれば点検もしておきます。Tautulliの設定（とくに通知やニュースレターのテンプレート置き場、登録メールアドレス）に見覚えのない変更がないか、管理画面のユーザー一覧に身に覚えのないアカウントがないかを確認してください。万一の場合に備えるなら、Plexのアカウントのパスワード変更と、Tautulliが握っているPlexのアクセストークンの再発行まで行えば、盗まれた合鍵は無効化できます。合鍵が漏れたあとの後追いがいかに難しいかは、家庭内ネットワーク監視ツールPi.Alertの事例でも触れたとおりです。

概要を1分で

この記事が扱う脆弱性の全体像を表にします。確認すべきは、使っているTautulliが v2.17.2 より古いかどうか、そしてゲストアクセスを有効にしているかどうかの2点です。

自宅サーバーやオープンソースの自己ホスト型ツールに複数の穴が同時に見つかるのは、これが初めてではありません。家庭内ネットワークの見張り役だったPi.Alertの認証なしRCEや、社内ログイン基盤authentikの複数脆弱性も同じ系統で、「守るための道具が、逆に侵入の入口になる」という共通点があります。今回のTautulliもその一例です。

何が起きるのか、まず一言で

ひとことで言えば、「来客用の入口から、家の奥まで通り抜けられる経路がいくつも残っていた」という話です。Tautulliには、来客レベルの権限しか持たない「ゲストユーザー」でも触れる窓口や、ログインせずに叩ける窓口があります。本来そこから先には進めないはずでしたが、入力のチェックや本人確認が抜けていたために、攻撃者がその隙間を使って一段ずつ奥へ入り込めてしまいました。

v2.17.1 で塞がれた5件の内訳は、サーバーに身代わりで通信させて家庭内ネットワークを覗き見る攻撃（CVE-2026-43986）、管理者の画面の中で攻撃者のスクリプトを走らせる攻撃（CVE-2026-43984）、管理者をだまして設定を書き換えさせる攻撃（CVE-2026-43985）、テンプレートの仕組みを悪用してサーバー上でコードを実行させる攻撃（CVE-2026-41065）、そしてファイルの置き場所をさかのぼるパストラバーサル（CVE-2026-40605）です。

そのうえで v2.17.2 が、さらに4件を塞ぎました。設定インポートのパストラバーサルによる任意ファイル書き込み（CVE-2026-52835、High）、/search の反射型XSS（CVE-2026-45381、Medium）、ニュースレターのcron値を経由した蓄積型XSS（CVE-2026-49995、Medium）、/auth/redirect のオープンリダイレクト（CVE-2026-54915、CVSS 5.4）の4件です。この4件は2026年8月17日時点でNVDに未登録で、EPSSも算出されていません。情報が薄いぶん見落とされやすいのですが、「v2.17.1以下」が対象である以上、v2.17.1 は安全なバージョンではありません。

インターネットに公開していなくても、成立する攻撃があります

Tautulliの脆弱性を調べた人が最初にたどり着く判断は、たいてい「うちは外に出していないから大丈夫」です。ポート開放もしていない、リバースプロキシも立てていない、家のWi-Fiの中でしか開かない。だから関係ない、と。この判断は、5件のうち1件については成り立ちません。

その1件が CVE-2026-43985、危険度8.8のCSRFです。CSRF（クロスサイト・リクエスト・フォージェリ）は、ログイン中の利用者を罠サイトに誘導し、本人が気づかないうちにその利用者の権限で操作を実行させる手口を指します。CVSSベクタの PR:N が示すとおり、攻撃者側にアカウントは要りません。必要なのは、Tautulliにログインしたままの管理者が、悪意あるページを1回開くことだけです。

その1回で何が起きるか。罠ページからTautulliの設定変更窓口 /configUpdate へリクエストが飛び、管理者のユーザー名とパスワードが攻撃者の指定した値に上書きされます。上書きされた時点で、管理画面の持ち主が入れ替わります。ブラウザは家のLANの中にいるので、Tautulliから見れば正規の管理者からの操作にしか見えません。

なぜLANの中まで届くのか。ブラウザには、他サイトからの通信に対してログイン情報（Cookie）を送るかどうかを制御する SameSite という仕組みがあります。既定値の Lax は、他サイトに埋め込まれた画像やスクリプトからの通信ではCookieを送りませんが、リンクを踏んでページそのものが移動する「トップレベルのクロスサイト遷移」では送ります。この抜け道が残っているため、罠ページから家庭内アドレスのTautulliへ遷移させれば、ログイン済みのセッションが一緒に付いていきます。ルーターのポートを閉じていても、リバースプロキシで認証をかけていても、管理者のブラウザ自体が内側にいる以上、この経路は閉じません。

v2.17.1 の修正では、CSRFトークン（正規の画面から来た操作であることを示す使い捨ての合言葉）の追加と、設定変更をPOST方式に限定する対策が入りました。この1件を塞ぐ手段は、更新以外にありません。ネットワーク構成をどれだけ丁寧に組んでも代替にならない、というのがこの脆弱性の性質です。

自分の環境の危険度チェック

5件が自分にどう効くかは、使い方によって変わります。よくある3つの形について、主要4件がそれぞれ成立するかどうかを整理しました。自分がどの行にいるかを先に決めてから読んでください。

どの行にいるかを決めるには、Tautulliの画面で次の3つを確認してください。

• ゲストアクセスを有効にしているか。家族や友人にPlexを共有していて、その人たちがTautulliの画面も見られる状態なら「有効」です。SSRFとXSSの2件は、仕込みにゲスト権限を使います。
• セットアップウィザードを完了しているか。入れたまま初期設定を途中で止めている環境は、後述のとおり最悪ケースです。
• HTTPのユーザー名・パスワードを設定しているか。Settings → Web Interface で確認できます。未設定なら、Tautulliは認証そのものを行いません。

リバースプロキシは万能ではありません

リバースプロキシとは、外からの通信をいったん受け止めて、内側のアプリへ中継する門番のようなサーバーのことです（NGINXやApacheがよく使われます）。ここで認証をかければ安全、と考えたくなりますが、CVE-2026-43986 については注意が要ります。SSRFの発火経路である /image/<ハッシュ>.png は、Tautulli側で認証を要求しません。プロキシ層で明示的に認証をかけていない限り、このパスへのリクエストはそのまま通過します。「Tautulliにログインしないと何もできないはず」という前提が、このパスだけ成立しないということです。

新規インストール直後がいちばん危ない

CVE-2026-41065 が最も危険なのは、入れたばかりの環境です。TautulliはHTTPのパスワード（HTTP_PASSWORD）が未設定だと、内部の認証フラグ AUTH_ENABLED を False にします。この状態では管理エンドポイントが全部無認証で開きます。セットアップウィザードを途中まで進めて、そのまま数日放置した環境が、この脆弱性における最悪ケースです。導入するときはネットワークの内側で初期設定を最後まで済ませ、最初から v2.17.2 を入れてください。

そもそもPlexとTautulliは何をする道具なのか

Plexは、自分が持っている映画・ドラマ・音楽・写真を、自宅のパソコンやNAS（ネットワーク対応の保存機）にためておき、スマホやテレビからNetflixのような見た目で再生できるようにするソフトです。家庭の「自前の動画配信サーバー」として、世界中の動画好き・自宅サーバー好きに使われています。

そのPlexに後付けする「視聴記録ノート」にあたるのが、今回問題になったTautulliです。誰が・いつ・何を再生したか、回線の混み具合、よく見られている作品などをグラフで見せてくれるほか、新着のお知らせメールを家族に配ったり、視聴があったときにスマホへ通知を飛ばしたりできます。GPL-3.0のオープンソースソフトで、GitHubのスターは6,566、フォークは632。PlexPyと呼ばれていた時代から数えると2015年から続くプロジェクトです。

利用者がどこで動かしているかは、配布の数字にはっきり出ています。Docker Hubのpull数は linuxserver/tautulli が約9.9億、tautulli/tautulli が約2.1億。一方でWindowsインストーラのダウンロード数は、v2.17.2 で10,957、v2.17.1 で9,080です。この桁違いの差は、利用者の圧倒的多数がDockerやNASの上で動かしていることの傍証です。ただしDockerのpull数は、CIの実行やイメージ更新のたびに増えるため、そのまま実利用者数として読むことはできません。あくまで比率の話として見てください。この記事が「Dockerでの更新手順」を先に書いているのは、そういう理由です。

問題は、このTautulliが置かれている場所です。Plexの利用統計を取るために、TautulliはPlexのアカウント情報やアクセス用の合鍵（トークン）を手元に持ち、サーバー本体や家庭内ネットワークの内側で動いています。外出先からスマホでグラフを見たい人は、Tautulliの画面をインターネットに公開していることも珍しくありません。「家の中の事情をよく知っている管理ツールを、外から触れる場所に置いている」——この構図が、今回の脆弱性の影響を大きくしています。

視聴記録ノートが侵入の足場に変わるとき、家から出ていくもの

「9.9」という数字を見ても、自宅サーバーの管理ツールが他人事に感じられるかもしれないので、この穴を実際に誰が何のために狙うのかを描いておきます。Tautulliの画面は、家庭内の事情をよく知る案内人のようなものです。その案内人を外から操れるとなれば、興味を持つ人間ははっきりしています。

狙ってくるのは、インターネットを四六時中スキャンして無防備な管理画面を探し回る自動化ボットの運用者、無料で観られる他人のPlexサーバーのリストを売り買いする海賊版コミュニティの住人、そして同じ家のWi-Fiにいる居候や別れた同居人です。彼らが欲しがるのは抽象的な「個人情報」ではありません。Plexのログイン情報とサーバー用の合鍵、家族の写真や自分で取り込んだ蔵書がどのフォルダに置いてあるかという地図、同じネットワークにつながったNASの中の確定申告書類や年賀状の住所録、そしてルーターの管理パスワードまで、具体的な中身です。本人確認の抜けた窓口に手を入れられた瞬間、それまで家の中だけにあったこれらの情報が、外の相手の手元へ流れ出します。

技術的に見ると、今回の連鎖はとくに相性が悪い組み合わせです。身代わり通信の穴（SSRF）は、Tautulliのサーバーに「内側からしか見えないはずの機器」へアクセスさせる足場になります。攻撃者は自分のパソコンからは届かないルーターの設定画面やNASの管理ページを、Tautulli経由で叩けるようになるわけです。さらにコード実行の穴（CVE-2026-41065）を使えば、サーバーの中で直接プログラムを走らせられます。入口は「視聴グラフを見せるだけ」の地味なツールでも、出口は家庭内ネットワーク全体です。

「CVSS 9.9」というラベルは、技術的な深刻度の天井を示しているだけです。自宅でPlexを回している人にとって本当に失われるのは、何年もかけて集めた映像コレクションへのアクセス、家族の写真が詰まったストレージの安全、そして「自分のサーバーは自分が握っている」という前提そのものです。数字よりも、その案内人の鍵を他人に渡さないことのほうが、ずっと切実なはずです。

深刻度9.9は何だったのか、攻撃の流れで追う

CVE-2026-43986 が9.9まで上がった理由は、単に「SSRFだから」ではありません。SSRF（サーバーサイド・リクエスト・フォージェリ）は、攻撃者がサーバーに「攻撃者の指定した場所へ通信しに行かせる」タイプの欠陥ですが、通常は認証済みの利用者しか起こせないので、もっと低いスコアに収まります。この件が跳ね上がったのは、3つの設計上の欠陥が重なって、仕込みと発火が別々の窓口に分離してしまったからです。

前提となる欠陥は次の3つです。（a）ゲスト権限しかない利用者が、画像のハッシュを生成する機能を使える。（b）そのハッシュが、すでに開示されていて、しかも攻撃者が操作できるデータから、決まった手順で導ける。（c）公開経路 /image/<ハッシュ> が、認証なしでデータベースの中身を無条件に信頼する。

攻撃の4段階

1と2にはゲスト権限が要りますが、3と4には何も要りません。ゲストアカウントを1つ作れる立場の人間が仕込みを済ませてしまえば、以後の発火は、世界中の誰でも、何度でもできます。

9.9まで跳ね上がった3つの理由

• 永続化される。攻撃者のURLはデータベースのテーブルに書き込まれ、消えません。一度仕込めば、そのTautulliは撃ち続けられる状態になります。
• 管理者のトークンにフォールバックする。未認証のリクエストが画像プロキシに届くと、内部の PmsConnect() はゲストの資格情報ではなく管理者のPlexトークンを使います。つまりSSRFが管理者権限で走ります。
• Scope Changed。CVSSベクタの S:C は、影響がその製品の権限境界を越えることを意味します。TautulliからPlex本体、LANの内部、クラウドのメタデータ取得先まで届きうる、という評価です。

修正は2本のコミット、そして2本目が重要

修正はいずれも2026年4月26日に入っています。1本目のコミット 85f9cc2は、外部のHTTP URLはそもそもデータベースに保存しないという1行の条件追加です。仕込みの経路を閉じる修正で、これは想像しやすいでしょう。

問題は2本目のコミット 137c966です。こちらは、すでに仕込まれていた汚染エントリを、アップグレード時にデータベースから一掃する処理を追加しています。開発者が「仕込みを止める」だけでなく「すでに仕込まれている前提で掃除する」コードを書いた、ということです。

ここが更新をためらう人に伝わりにくい点だと思います。「パッチを当てれば汚染は消える」のではなく、「パッチを当てて初めて掃除される」のです。v2.17.1 より前のバージョンを動かし続けている環境に、すでに攻撃者のURLが1行書き込まれていたとしても、更新しない限りその行は残り続け、/image/ を叩かれるたびに発火します。開発者自身が「既に仕込まれている可能性」を想定していた、という事実こそが、更新の必要性を示す一次的な証拠です。

5件の脆弱性、それぞれ何が危ないのか

v2.17.1 のリリースノートに記載された5件を、危険度の高い順に解説します。それぞれ単体でも問題ですが、組み合わせると被害が大きくなる関係にあります。

CVE-2026-43986：サーバーに身代わり通信をさせる穴（深刻度9.9）

5件のなかで最も深刻です。正式な分類はCWE-918（サーバーサイド・リクエスト・フォージェリ、SSRF）、CVSSは9.9でベクタは AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L。仕込みにはゲスト権限が要りますが、発火は完全に未認証です。攻撃の流れは前節のとおりで、修正では外部画像のURLを保存しないよう変更されたうえ、既存の汚染エントリを削除する処理が加えられました。

CVE-2026-41065：テンプレートインジェクションによるコード実行（深刻度8.9）

当初この記事では「お知らせメール機能から任意コード実行」と書いていましたが、実態はテンプレートインジェクションです。分類はCWE-1336（テンプレートエンジンにおける式の不適切な無害化）。Tautulliはニュースレターの見た目をMakoというテンプレートエンジンで組み立てますが、攻撃者が用意したテンプレートを読み込ませると、その中に書かれた式がそのまま評価され、サーバー上でコードが走ります。ファイルを実行させているのではなく、テンプレートの記法そのものが実行経路になっているという違いです。

CVSSは4.0のみが付与されており、8.9 HIGH、ベクタは PR:N/UI:N/E:P。セットアップが完了していない環境では完全に未認証で成立し、完了済みの環境では管理者権限が必要という、条件が二段構えの脆弱性です。入口の検証不足がコード実行に化ける構図は、AI開発ツールLangflowの認証なしRCEやファイル共有Sambaの認証なしRCEでも繰り返し見てきたものです。

CVE-2026-43984：管理者の画面の中でスクリプトを走らせる穴（深刻度8.9）

分類はCWE-79（クロスサイト・スクリプティング、XSS）の蓄積型。Webページに攻撃者のスクリプトを忍ばせ、それを別の人のブラウザで実行させる手口です。ベクタは PR:L/UI:R/S:C で、注入にはゲスト権限が要り、発火は管理者がログビューアを開くことが条件になります。Tautulliには画面側のエラーを記録する窓口（log_js_errors）があり、ここに来客レベルのゲストが好きな文字列を流し込めました。その文字列は加工されないまま記録に残り、管理者が記録閲覧画面を開いたときに、攻撃者のスクリプトがそのまま動きます。管理者の権限で走るため、設定の改ざんやセッションの乗っ取りにつながります。

CVE-2026-43985：管理者をだまして設定を書き換えさせる穴（深刻度8.8）

分類はCWE-352（クロスサイト・リクエスト・フォージェリ、CSRF）。ベクタは PR:N/UI:R/S:U で、攻撃者側に認証は要りません。ログイン中の管理者を罠サイトへ誘導すれば成立します。詳しくは前述の「インターネットに公開していなくても、成立する攻撃があります」のとおりで、5件のなかで唯一、ネットワークをどう組んでも防げない性質を持っています。

CVE-2026-40605：保存ファイルを消せる経路（パストラバーサル）

分類はCWE-22（パストラバーサル）とCWE-73（ファイル名やパスの外部からの制御）。パストラバーサルとは、「../」のような相対パスを使って、本来アクセスできない上位フォルダへさかのぼる手口です。Tautulliのキャッシュ削除機能にこの抜け道があり、想定外の場所のファイルを削除できる恐れがありました。CVSSは4.0のみで5.7 MEDIUM、ベクタに PR:L が付いており、APIキーによる認証済みアクセスが必要です。5件のなかでは成立条件が最も重い1件になります。

なぜまとめて見つかったのか、技術的に見ると

5件に共通するのは、「外から渡された値を、十分に確かめないまま内部で使ってしまった」という根っこです。身代わり通信の穴は外部アドレスを、コード実行の穴はテンプレートの中身を、画面内スクリプト実行の穴はエラー記録の中身を、いずれも来客レベルの相手が指定できる入力として受け取り、検証を挟まずに処理に流していました。設定書き換えの穴は逆に、操作の出どころを確かめる仕組みが足りていませんでした。入力の確認と、本人の確認。この2つの基本がところどころで抜けていた、という整理になります。

そして、これは単発の事故ではありません。Tautulli自身のCVE履歴を並べると、2025年9月のv2.16.0で4件、2026年3月のv2.17.0で5件、2026年5月のv2.17.1で本件の5件、2026年6月のv2.17.2で4件。直近12か月で計18件です。品質が急に落ちたというより、外部の研究者の注目が集まって継続的に掘られている状態、というのが正確な描写でしょう。同じコードベースを別々の研究者が別々の角度から見れば、似た種類の穴がまとまって出てきます。

この見立てを裏づけるのが、v2.17.0のバッチを報告した研究者 Matt Andreko 氏の調査記事です。同氏は「多くの人がTautulliを自宅ネットワークに、あるいはインターネットに直接公開して動かしている」と指摘したうえで、「HTTPパスワード未設定の場合、訪問したあらゆるWebページがAPIキーを盗める」と書いています。研究者から見て、狙う価値があり、かつ守りが甘い対象だと認識されている、ということです。

こうした「自己ホスト型の便利ツールに、認証や認可の穴がまとめて見つかる」事例は最近とくに目立ちます。盗まれた合鍵や設定が、別のシステムへの侵入の踏み台に転用されていく流れは、オープンソース部品を経由した攻撃の連鎖とも地続きです。ログインまわりの作り込みが甘いまま公開されてしまう問題は、解析ツールJupyterのログイン画面の不備やシングルサインオン基盤Casdoorの認証回避、問い合わせ管理OTRSの認可回避でも続いており、Tautulliもその列に並びます。

影響を受けるバージョンと、修正の状況

まず v2.17.1 で塞がれた5件を、CWE分類・CVSS・成立条件つきで並べます。CVSSは、脆弱性の深刻さを0〜10で表す国際的な共通スコアです。なお、この5件のスコアはすべてGitHubによる二次評価で、NVD独自のスコアは付いていません。また、CVE-2026-41065 と CVE-2026-40605 の2件はCVSS 4.0のみで、v3.1のスコアが存在しません。

v2.17.2 が追加で塞いだ4件

こちらが、この記事を書き換えることになった理由です。2026年6月16日公開の v2.17.2 は、「v2.17.1以下」を影響範囲とする4件を修正しています。上の5件を塞いだはずの v2.17.1 が、その時点で新たに4件を抱えていたことになります。

この4件は、2026年8月17日時点でNVDに未登録で、EPSSも算出されていません。検索してもNVDのページが出てこないため、存在に気づきにくい状態です。それでも影響範囲は「v2.17.1以下」であり、v2.17.2 のリリースノートに修正として明記されています。あわせて v2.17.2 では、v2.17.1 で導入された X-Api-Key ヘッダーのチェックがサーバーをクラッシュさせる不具合も直っています。

深刻度9.9でも、実際に攻撃される確率は低いままです

ここまで危険性を書いてきましたが、実際の攻撃状況は落ち着いています。数字を正直に並べます。

まず、CISA KEV（米国のサイバーセキュリティ機関が「実際に悪用が確認された」と判断した脆弱性だけを載せるカタログ）には、5件とも収載されていません。2026年8月14日版のカタログ1,665件と照合した結果です。それどころか、Tautulliという製品自体が、過去も含めてKEVに一度も載ったことがありません。KEVの見方についてはこちらの記事にまとめています。

次にEPSS（今後30日以内にその脆弱性が実際に悪用される確率を統計的に推定する指標）です。5件とも0.5%を下回っています。

目を引くのは、深刻度が最も高い CVE-2026-43986 のEPSSが0.00262、順位でいえば下位18.2パーセンタイルという点です。CVSSは「うまく突かれたらどれだけひどいか」を測る指標、EPSSは「実際に突かれそうか」を測る指標なので、この2つが逆方向を向くこと自体は珍しくありません。9.9という数字と、攻撃者の関心の低さは、両立します。

NVD側の状況も静かです。5件とも Deferred、つまりNVDが今後この脆弱性を追加分析しない状態になっており、2026年7月22日を最後に更新がありません。前述のとおり、CVSSはGitHubによる二次評価のみで、NVD独自のスコアは5件とも付いていません。実際の悪用報告、被害報告、ハニーポットでの観測、ボットネットによるスキャンの報告は、いずれも確認できていません。

実証コード（PoC）については、正確に書いておきます。GitHubにもExploit-DBにも、この5件の実証コードのリポジトリは1件もありません。ただし、GitHub Security Advisoryの本文に、攻撃手順が完全な形で載っています。とくにCVE-2026-41065のアドバイザリには、悪性テンプレートの中身と、攻撃に使う3つのHTTPリクエストがそのまま掲載されています。「実証コードのリポジトリはないが、攻撃手順は公開されている」というのが実態です。加えて、CVSS 4.0のベクタを持つCVE-2026-41065とCVE-2026-40605には E:P（実証コードが存在する）が付いています。

国内の状況も確認しておきます。JVN iPediaに本件5件は登録されていません。ただしTautulli自体は継続して登録があり、2026年3月のv2.17.0のバッチ分は JVNDB-2026-010979 などで登録済みです。JPCERT/CCやIPAからの注意喚起、国内での報道も確認できていません。

ここから読み取るべきなのは、「危険がない」ではなく「いま緊急の夜間メンテナンスを組む段階ではない」ということです。次の計画メンテナンスの枠で v2.17.2 に上げれば十分です。ただし、前述のCSRFの1件だけは公開・非公開を問わず成立するので、先送りの理由にはなりません。

それでも更新が必要な理由、LastPass侵害の起点はPlexでした

「悪用報告がないなら急がなくていい」という判断が、どこまで通用するのか。抽象的な警告よりも、実際に起きた話のほうが早いと思います。

2022年、パスワード管理サービスのLastPassが大規模な侵害を受けました。その起点は、同社のシニアDevOpsエンジニアの自宅PCで動いていた、更新されていないPlex Media Serverです。CVE-2020-5741というPlexのコード実行の脆弱性が突かれ、そのPCにキーロガー（キーボード入力を盗み取るプログラム）が仕込まれました。そこから企業の内部保管庫の鍵が盗まれ、最終的にパスワード管理サービスの利用者数百万人に影響する侵害へと発展しています。

この件で押さえておきたいのは、CVE-2020-5741はPlex Media Server 1.19.3ですでに修正済みだったということです。更新していれば防げました。この脆弱性はCISA KEVに2023年3月10日付で収載されています。「自宅の趣味のサーバー」と「勤務先の本番環境」は、同じ人間が同じPCから触っている以上、地続きです。

では呼びかければ更新されるのか、という点も数字があります。2025年8月に公表されたPlex Media Serverの情報漏えいの脆弱性（CVE-2025-34158）では、Plexが利用者へ異例のメール通知まで行いました。それでも、インターネット全体をスキャンしているCensysの観測によれば、2025年8月25日時点でも314,000台以上が脆弱なままでした。開発元が個別にメールを送っても、この規模で更新されずに残ります。

Tautulliに戻ると、直近12か月で18件のCVEが出ています。個々の悪用確率は低くても、脆弱なまま動き続けるサーバーが積み上がっていけば、どこかで誰かの入口になります。LastPassの件は、その「どこかで誰か」が現実に起きた記録です。

Tautulliを外に出すべきか、公式FAQの序列を読む

外出先からグラフを見たい、という需要は現実にあります。Tautulli公式のFAQは、外部からアクセスする方法として3つを序列つきで挙げています。

この表を素直に読むと、奇妙なことに気づきます。公式が自ら「最も安全性が低い」と書いている方法が、選択肢の1番目に案内されているのです。手順の説明としては簡単な順に並べる理由がありますが、読む側は上から順に試します。そして、いちばん上に書いてあるポートフォワーディングは、この記事で扱った脆弱性のうち最悪ケース（セットアップ未完了＋直接公開）を作る方法でもあります。

公式は前提として、「これらを実行する前に、Settings → Web Interface でHTTPのユーザー名とパスワードを設定し、認証を有効にしていること」と警告しています。この前提が守られていない環境では、Tautulliは AUTH_ENABLED = False の状態で外に出ることになります。前述のMatt Andreko氏の指摘「HTTPパスワード未設定の場合、訪問したあらゆるWebページがAPIキーを盗める」は、まさにこの状態を指しています。

この記事としての推奨は、3番目のVPNトンネルを第一選択にしてください、です。かつては「最も不便」でしたが、いまはTailscaleのようなツールで、ルーターの設定を触らずに端末同士を直接つなげられます。スマホにアプリを入れて同じアカウントでログインすれば、外出先からでも家庭内アドレスのままTautulliを開けます。ポートを1つも開けずに済むので、この記事で挙げた脆弱性のうち「外部からの到達」を前提とするものは、成立条件そのものが消えます。

リバースプロキシを選ぶ場合は、前述のとおり /image/ の扱いに注意してください。プロキシ層で認証をかけていないと、SSRFの発火経路はそのまま通ります。そして繰り返しになりますが、どの方式を選んでもCSRFの1件は残ります。ネットワーク構成は更新の代わりにはなりません。

これまでの経緯

修正コミットから現在までの流れを時系列で整理します。修正が先に配られ、利用者が更新する時間を確保したうえでCVE番号が公開される、という順序が取られています。

← スワイプで移動

よくある質問

Q. v2.17.1 にはもう上げてあります。それで十分ですか？

A. 足りません。2026年6月16日公開の v2.17.2 が、「v2.17.1以下」を対象とする4件（CVE-2026-52835／CVE-2026-45381／CVE-2026-49995／CVE-2026-54915）を追加で修正しています。2026年8月17日時点の安全な最低バージョンは v2.17.2 です。

Q. 家のネットワークの中だけで使っているなら安全ですか？

A. 安全ではありません。CVE-2026-43985（CSRF、危険度8.8）は攻撃者側の認証が不要で、Tautulliにログインしたままの管理者が悪意あるページを開くだけで成立します。ブラウザのSameSite=Laxがトップレベルのクロスサイト遷移を許すため、罠ページからLAN内のTautulliへ、ログイン済みのセッションごと届いてしまいます。ポート開放の有無は関係ありません。

Q. リバースプロキシで認証をかけているので大丈夫では？

A. 万能ではありません。CVE-2026-43986（SSRF）の発火経路 /image/<ハッシュ>.png はTautulli側で認証を要求しないため、プロキシ層で明示的に認証をかけていない限り通過します。またCSRFの1件は、前述のとおりプロキシでは防げません。

Q. 深刻度9.9なのに、EPSSが下位18.2パーセンタイルなのはなぜですか？

A. CVSSは「うまく突かれたらどれだけひどいか」、EPSSは「今後30日以内に実際に突かれそうか」を測る、目的の違う指標だからです。CVE-2026-43986は、成立させるのにゲストアカウントを1つ用意する必要があり、対象も自宅サーバー中心です。攻撃者にとって割に合う標的とは見なされていない、という状態が数字に出ています。

Q. 実証コードは公開されていますか？

A. GitHubにもExploit-DBにも、実証コードのリポジトリは1件もありません。ただしGitHub Security Advisoryの本文に攻撃手順が完全な形で載っています。とくにCVE-2026-41065のアドバイザリには、悪性テンプレートの中身と3つのHTTPリクエストがそのまま掲載されています。「実証コードのリポジトリはないが、攻撃手順は公開されている」というのが正確な状況です。

Q. 入れたばかりのサーバーが一番危ないと聞きました。なぜですか？

A. TautulliはHTTPのパスワード（HTTP_PASSWORD）が未設定だと AUTH_ENABLED = False になり、管理エンドポイントが全部無認証で開くためです。この状態ではCVE-2026-41065が完全に未認証で成立します。セットアップ途中で放置した環境が最悪ケースなので、導入時はネットワークの内側で初期設定を最後まで済ませてください。

Q. Plexは使っていますが、Tautulliは入れていません。影響はありますか？

A. この記事の脆弱性はTautulli側の問題なので、Tautulliを入れていなければ直接の影響はありません。ただしPlex本体にも過去に深刻な脆弱性があり、CVE-2020-5741は2022年のLastPass侵害の起点になっています。Plex Media Server自体も最新版に保ってください。

最新の安全バージョン

更新履歴

参照元

• ▸ Tautulli v2.17.2 リリースノート（4件の追加修正・X-Api-Keyクラッシュ修正）（2026年6月16日）
• ▸ Tautulli v2.17.1 リリースノート（セキュリティ修正一覧）（2026年5月5日）
• ▸ Tautulli リリース一覧（GitHub）
• ▸ GitHub コミット 85f9cc2 - 外部HTTP URLをDBに保存しない修正（2026年4月26日）
• ▸ GitHub コミット 137c966 - 既存の汚染エントリをアップグレード時に一掃するDB処理（2026年4月26日）
• ▸ Tautulli GitHub Security Advisories（攻撃手順を含むアドバイザリ本文）
• ▸ NVD - CVE-2026-43986 Detail（SSRF・9.9・Deferred）
• ▸ NVD - CVE-2026-41065 Detail（テンプレートインジェクション・CWE-1336）
• ▸ NVD - CVE-2026-43984 Detail（蓄積型XSS）
• ▸ NVD - CVE-2026-43985 Detail（CSRF・認証不要）
• ▸ NVD - CVE-2026-40605 Detail（パストラバーサル・CWE-22 / CWE-73）
• ▸ Tautulli 公式FAQ（外部アクセスの3方式と、HTTP認証を有効にする前提条件）
• ▸ Matt Andreko - Tautulli Security Findings（v2.17.0バッチの発見者による調査記事）（2026年3月27日）
• ▸ CISA Known Exploited Vulnerabilities Catalog（2026年8月14日版・1,665件で照合）
• ▸ FIRST - EPSS（悪用可能性スコアの解説）
• ▸ NVD - CVE-2020-5741 Detail（Plex Media Serverのコード実行・2022年LastPass侵害の起点・KEV収載）
• ▸ NVD - CVE-2025-34158 Detail（Plex Media Serverの情報漏えい・2025年8月）
• ▸ Docker Hub - linuxserver/tautulli（pull数 約9.9億）
• ▸ Docker Hub - tautulli/tautulli（pull数 約2.1億）
• ▸ Tautulli 公式リポジトリ（GitHub・スター6,566 / フォーク632 / GPL-3.0）
• ▸ Plex 公式サイト