Jupyter Serverに偽サイト誘導の脆弱性、最新の2.20.0へ更新を

研究者やデータ分析者、大学生が世界中で使うウェブ上のプログラミング環境「Jupyter Server」は、バージョン2.17.0以前で、ログイン画面を偽サイト誘導（フィッシング）の踏み台にされる脆弱性を抱えています。管理番号はCVE-2025-61669。ログイン後の戻り先を決めるURLに細工をされると、正規のJupyter画面だと信じてログインした利用者が、攻撃者の用意した偽サイトへそのまま飛ばされます。この穴自体は2.18.0で修正済みですが、その後もより危険な脆弱性が続けて公開されており、いま導入・運用するなら最新の2.20.0以降にしておくのが安全です。2.19.0以下に留まると、後述するCVSS9.3（4段階で最上位の「緊急」）の別の脆弱性（CVE-2026-44727）が残ります。

問題はログイン後のリダイレクト先を決める next クエリパラメータの検証が甘い点にあります。/login?next=///example.com のようなURLを踏ませると、自社のJupyter画面だと信じてログインボタンを押した利用者が、攻撃者の偽サイトに連れて行かれてしまいます。CVE-2025-61669単体のCVSSは v3.1 で 6.1（中）、v4.0 で 6.3（中）。一見地味ですが、攻撃はネットワーク越しに成立し、ログインもパスワードも要らず、必要なのは利用者が細工リンクをクリックすることだけです。狙われるのは、機微なデータ・学習モデル・社内認証情報を握る研究者層です。

CVE-2025-61669の影響は Jupyter Server 2.17.0以前のすべてのバージョンに及び、修正が入ったのは2.18.0です。ただし2.18.0はこの1件だけを直したリリースではなく、同時に複数の脆弱性をまとめて塞いだ「束（たば）」の修正で、しかもその後の2.19.0・2.20.0でさらに別の欠陥が直っています。JupyterLab や Jupyter Notebook 7 は内部で Jupyter Server を呼ぶため同じ穴を抱え、JupyterHub で配信される多人数環境のユーザーサーバも例外ではありません。だからこそ「2.18.0という単一の修正版に上げれば終わり」ではなく、常に最新へ追従する運用が要ります。

研究データが他人の名前で先に発表されるシナリオ

スコアだけ見ると「中」程度のオープンリダイレクトですが、Jupyterにログインしているという事実そのものが、相手にとって「価値あるアカウント」のシグナルになります。なぜこの一見地味な穴が標的型で狙われるのか、その動機の側から整理しておきます。

この欠陥を踏みに来る相手は、ばらまき型フィッシング業者ではなく、特定の研究者・大学院生・社内データサイエンティストを名指しで狙う層です。大学研究室や国立研究機関を継続観察してプレプリント直前のデータを抜く学術スパイ、製薬企業やAIスタートアップの社内学習モデルを横流ししたい産業スパイ、大学院生を踏み台にBEC（ビジネスメール詐欺）で指導教員になりすます詐欺グループ、暗号資産研究や創薬計算の途中結果を欲しがる競合の内部協力者、論文投稿前夜やハッカソン中の高ストレス時間帯だけ動く標的型グループ。彼らが取りに来るのは、査読中のドラフトと未投稿の実験データ、学位論文の生データ、指導教員とのやりとり、社内LLMの学習データとプロンプト、創薬パイプラインの途中結果、SageMakerやAzure MLに紐づくAPIキーとS3トークン、自前のStable Diffusion重みなど、「数年分の労力が1ファイルに凝縮されたもの」です。本CVEを踏ませた相手は、本物のJupyterドメインのリンクで安心させた直後にそっくりな偽画面でパスワードを再入力させ、ノートブック・データセット・クラウド資格情報を芋づる式に持ち帰ります。ドメインが正規である段階でブラウザの警告は何も出ません。

この攻撃が刺さりやすい理由は、Jupyter利用者の行動様式と完全に噛み合っているからです。研究者は深夜にセッション切れで再ログインを迫られることに慣れており、URLのホスト部分が大学ドメインで一致していれば疑いません。さらに /login?next=///attacker.example.com/jupyter 形式は、メールクライアントのプレビュー上でも「自校ドメインのリンク」と見える。一度パスワードが渡れば、奪ったアカウントから同じJupyterHubに同居する他研究者の環境へ横展開も成立し、研究室単位で被害が広がります。さらにJupyter経由で叩けるS3やSageMakerの権限は、たいてい本人にしか紐付かないため、後から「誰がアクセスしたか」を切り分ける証跡が薄いという二次的な問題まで連れてきます。

スコア6.1はあくまでリダイレクト挙動の技術的な深刻度を測ったものですが、研究者・大学院生にとっての実損は数年かけて積み上げた未発表の成果と、博士論文の独自性そのものが、他人の名前で先に出版される、あるいは競合製品に「先回り」される事態です。研究の世界では、データはコピーされた瞬間にオリジナルでなくなります。

Jupyter Serverとは何か

Jupyter Server は、ブラウザの中で Python や R のコードを書きながら、その実行結果やグラフを一緒に保存できる「ノートブック」と呼ばれる仕組みの裏側で動くWebサーバです。ユーザーが直接触ることが多いのは、画面側の JupyterLab や Jupyter Notebook 7 のほうですが、その裏でファイル一覧・コード実行・ターミナル接続などのAPIを提供しているのが Jupyter Server です。

公式ドキュメントが「ほとんどのユーザーは Jupyter Server を直接インストールする必要はなく、JupyterLab や Notebook の依存として自動的に入る」と説明しているとおり、Jupyter Server は意識せず使われている土台です。日本国内でも次のような場面で広く使われています。

• 大学・大学院の機械学習・統計・データサイエンス系科目の演習環境
• 企業のデータ分析・MLチームが Google Colab の代わりに社内で立てる解析環境
• 研究室・公的研究機関のGPUサーバに JupyterHub を被せた多人数共用環境
• AWS SageMaker・Azure ML・Google Vertex AI など、各クラウドのマネージドノートブック
• 個人開発者が自宅 GPU マシンに立てる Stable Diffusion・LLM 実験環境

最近のリリースはいずれも内部で Jupyter Server を必ず呼びます。pip install jupyterlab や pip install notebook をした時点で、知らないうちに Jupyter Server が一緒に入る構造です。古いバージョンが残っていれば、意識しないまま脆弱な土台を動かしていることになります。

CVE-2025-61669の中身

脆弱性の根本は、Jupyter Server のログインハンドラ LoginFormHandler._redirect_safe() の検証不備にあります。問題のコードは jupyter_server/auth/login.py に置かれており、本来は「自サーバ配下のパスへの転送だけ許す」「CORS設定で許可されたドメインへのフル転送だけ許す」という二段構えの設計でした。NVDの分類はCWE-601（信頼されていないサイトへのURLリダイレクト）。

攻撃の作り方は驚くほどシンプルです。GHSAアドバイザリ GHSA-qh7q-6qm3-653w が示すPoCはこの一行に集約されます。

http://localhost:8888/login?next=///google.com

このURLを開くと、ログイン後の戻り先が本来の自サーバではなく Google に飛ばされます。攻撃者は google.com の位置に自分の偽サイトを置けば、利用者を任意の外部ドメインへ自由に誘導できます。

なぜ ///example.com という奇妙な形が通ってしまうのか。ブラウザは //example.com を「現在と同じスキーム（http/https）で example.com に行け」と解釈します（プロトコル相対URLと呼ばれる仕組み）。スラッシュを1本増やした ///example.com も同じく外部ドメインへ飛びます。一方、サーバ側の検証ロジックは「URLにスキームが付いていない＆ネットワーク部分が空っぽ」と判定して「これは自サーバ内部のパスだ」と勘違いし、許可してしまっていました。CWE-601の典型的な抜け穴です。

「ただのリダイレクト」がフィッシングの完成度を上げる理由

オープンリダイレクト（攻撃者が任意のURLへ転送できる穴）は、単独では情報を盗む力を持ちません。にもかかわらずOWASPが警戒対象として扱い続けているのは、フィッシング攻撃の「最後のピース」になるからです。

具体的に、研究室や社内JupyterHubでの攻撃シナリオはこうなります。

1. 攻撃者が、研究室の Jupyter サーバそっくりの偽ログイン画面を phish.example 等に用意する
2. 「サーバが再起動しました。再ログインをお願いします」というメールに、https://jupyter.lab.univ.ac.jp/login?next=///phish.example のような正規ドメインから始まるURLを添える
3. 受信者は jupyter.lab.univ.ac.jp の部分を見て安心し、クリックする
4. 正規のJupyter Serverに遷移し、ログイン画面が出る。ログイン後、リダイレクト先として ///phish.example が使われ、利用者は偽サイトに到着する
5. 偽サイトが「セッション切れです、もう一度パスワードを入力してください」と見せれば、認証情報を抜かれる

この流れの肝は、最初のクリック時点で表示されるドメインが 本物の研究室・本物の会社のものであること。メーラーのリンクプレビュー機能も、ブラウザのアドレスバーも、最初は「正規ドメイン」を表示します。SAML/OAuth でログインしている JupyterHub 環境では、認証情報の窃取はそのまま大学アカウント・社内アカウントの乗っ取りに直結します。

研究データやモデルそのものを抜きたい攻撃者にとって、Jupyter サーバの認証情報は最短経路です。社内で AWS SageMaker や Azure ML のノートブックを使っている場合は、クラウド側のIAMロールにも届きうるため、被害は単一サーバに留まりません。

JupyterLabとNotebook 7にも波及する

この脆弱性のもう一つの厄介な点は、Jupyter Server を「自分で入れた覚えがない」ユーザーにも影響することです。JupyterLab と Jupyter Notebook 7（俗に言う「Classic Notebook の後継」）は、いずれも内部で Jupyter Server を呼び出して動いています。notebookパッケージの依存関係Issueを見るとわかる通り、Notebook 7.1以降は jupyter_server を必須依存に持ちます。

影響を受ける構成例を整理すると次の通りです。

対処の入口は pip install -U jupyter_server または conda update jupyter_server で最新の 2.20.0 以降にバージョンを上げることです。PyPIの最新版と環境のバージョンが揃っているかを確認してから、JupyterLab や Notebook を起動し直す流れになります。

注意したいのが、Anaconda などのディストリビューションや、社内の固定リポジトリで止まっているケース。jupyter --version で jupyter_server の行を確認し、最新の2.20.0に届いていなければ個別に上げてから戻すのが安全です。

2.18.0で終わりではない。その後に出た、より危険な脆弱性

この記事の本題はオープンリダイレクトですが、Jupyter Server はその後も断続的にセキュリティ修正を重ねています。「2.18.0へ上げれば安心」で止めず最新へ、と繰り返すのはこのためです。とくに次の1件は、本記事のオープンリダイレクトより明らかに重大で、しかも2.18.0・2.19.0では直っていません。

CVE-2026-44727：nbconvert経由の保存型XSS（CVSS9.3・緊急）

ノートブックをHTMLなどに変換する部品 nbconvert のHTTPハンドラで、返すHTMLに安全策（sandbox指定という、埋め込まれたスクリプトの実行を封じる設定）が抜けていました。この結果、ページに仕込まれた不正なスクリプトが、後からそれを開いた人のブラウザ上で勝手に実行される「保存型XSS」が成立します。深刻度はCVSS v4.0で9.3、4段階で最上位の「緊急（Critical）」。ここから利用者のcookie（ログイン状態を保つ小さな認証データ）を盗まれ、/api/ 系の操作権限を奪われ、最終的にはコードを実行するカーネル経由で任意の命令実行にまで至りうるとされています。影響は2.19.0以前で、修正は2.20.0。2.18.0や2.19.0に留まっていると、この緊急の穴がそのまま残ります。いま「2.20.0以降」を推す最大の理由がこれです。

同時に塞がれた、その他の脆弱性

2.18.0は、実はCVE-2025-61669だけを直したリリースではありません。リリースノートを見ると、同じ2.18.0で CVE-2026-40110 と CVE-2026-35397 という別の脆弱性も一緒に修正されています。さらに CVE-2026-40934 は、パスワードを変更しても以前のセッション用cookieが有効なまま残ってしまう認証まわりの不備（変更後も古い認証が使えてしまう「セッション失効の不足」）で、これも2.18.0で対処されました。画面側の CVE-2026-40171 は Jupyter Notebook 側の保存型XSSで、認証トークンを盗まれる欠陥です。単一のCVE番号だけを追っていると、これらの束（たば）の修正を取りこぼします。

なお、CVE-2025-61669 は2026-07-23時点で、米政府CISAがまとめる実際に攻撃されている脆弱性リスト（KEV）には登録されておらず、公開情報でも実証コード（PoC）が示されている段階で、広範な悪用の報告は確認されていません。とはいえ公開から2ヶ月以上が経ち攻撃の仕組みは公開済みで、より重大なCVE-2026-44727まで含めれば、最新へ上げない理由はありません。

報告は日本のCyber Defense Institute

CVE-2025-61669の報告者は、東京の独立系セキュリティ企業 Cyber Defense Institute の Noriaki Iwasaki 氏。同社はペネトレーションテスト・フォレンジック・マルウェア解析を主軸にした老舗で、これまでも EC-CUBE など国内外OSSの脆弱性を JPCERT/CC 経由で報告してきた実績があります。

GHSA アドバイザリのクレジット欄には、報告者 Iwasaki 氏に加えて、調整役として Jupyter コアチームの Yann-P、Carreau（IPython/Jupyter の中心開発者として知られる Matthias Bussonnier 氏）、修正実装は dlqqq（Jupyter AI のリード開発者 David L. Qiu 氏）が名を連ねています。日本人研究者の報告→ Jupyter コアチーム内での調整→2.18.0 でのリリースという、CVD（協調的脆弱性開示）の手順を踏んだ流れでした。

GitHub 上のアドバイザリ公開が2026年5月5日、JPCERT/CC を介したJVN#01719116としての国内公開が同年5月28日で、約3週間遅れての国内通知でした。日本の利用者の多くは英語圏のセキュリティ通知を直接追っていないため、JVN 公開を契機にアップデートの周知が国内研究機関・SIerに広がる構図はよく見られるパターンです。

研究者・運用者がいま取るべき行動

フィッシングは「人が引っかかるかどうか」の問題に見られがちですが、攻撃者がドメインを偽装できるかどうかは技術側で確実に潰せます。Jupyter Server の運用責任者・個人利用者ともに、以下を推奨します。

• jupyter_server を最新の 2.20.0 以降に更新する（2.18.0・2.19.0では緊急のCVE-2026-44727が残る）
• 一度上げて終わりにせず、Jupyter Server は継続的に修正が出る土台なので、定期的に最新へ追従する運用にする
• JupyterHub 運用環境では、各ユーザーが生成するサーバ（singleuser）のイメージや conda 環境の jupyter_server も同時に更新する
• SageMaker / Vertex AI / Azure ML 等のマネージドノートブックを使っている場合は、各クラウドベンダーのセキュリティ情報を確認し、再起動・イメージ更新のタイミングを把握する
• 研究室・社内向けに「Jupyter のログイン URL に ?next= が含まれていたら踏まない」周知を行う
• リバースプロキシ（Nginx / Apache）側で、/login へのアクセスを社内ネットワークに限定する設定も併用する

中長期的には、本サイトのCISA KEVダッシュボードのような既知の悪用済み脆弱性リストを定期的にチェックする運用と、OSSサプライチェーンスキャナーのような依存パッケージの自動監視を組み合わせるのが、こうした「内部に静かに入っているOSS」の脆弱性をすばやく検知する近道です。Jupyter Server のように「ユーザーが自分で入れた覚えがない依存」こそ、自動監視の出番です。

まとめ

CVE-2025-61669 は CVSS 6.1 という数字だけ見ると「中」程度ですが、対象が世界中のデータ分析・AI 研究の土台となる Jupyter Server で、JupyterLab・Notebook 7 にも自動で波及し、研究者・大学アカウントという価値の高い認証情報に直結する点で軽視できません。この穴自体は2.18.0で塞がれています。

ただし Jupyter Server は2.18.0のあとも、2.19.0以前を襲うCVSS9.3のXSS（CVE-2026-44727）など、より重大な脆弱性の修正を重ねてきました。2026-07-23時点で安全なのは最新の2.20.0以降で、これらはKEVにも載らず広範な悪用も確認されていませんが、仕組みは公開済みです。手元の pip list や jupyter --version で jupyter_server の版を確かめ、2.20.0未満なら上げておくこと。そして「一度上げれば終わり」ではなく、継続的に最新へ追従する運用が、この土台を安全に保つ現実的な答えになります。

参照元

• ▸ GitHub Security Advisory — GHSA-qh7q-6qm3-653w（CVE-2025-61669）
• ▸ NVD — CVE-2025-61669
• ▸ JVN#01719116 — Jupyter Serverにおけるオープンリダイレクトの脆弱性（JPCERT/CC）
• ▸ GitHub Security Advisory — GHSA-fcw5-x6j4-ccmp（nbconvert XSS / CVE-2026-44727、CVSS9.3・2.20.0で修正）
• ▸ jupyter_server リリースノート（2.18.0〜2.20.0 の修正内容）
• ▸ jupyter_server/auth/login.py（修正後のコード）
• ▸ jupyter-server — PyPI（最新版の確認）
• ▸ Cyber Defense Institute, Inc.（報告者所属）
• ▸ OWASP — Open Redirect
• ▸ CWE-601: URL Redirection to Untrusted Site