Jupyter Serverにフィッシング誘導の脆弱性 CVE-2025-61669、研究者のログイン画面が標的

世界中の研究者・データ分析者・大学生が使うウェブ上のプログラミング環境「Jupyter Server」に、ログイン画面を踏み台にしたフィッシング誘導を許す脆弱性CVE-2025-61669が見つかりました。日本のセキュリティ企業Cyber Defense Instituteの研究者 Noriaki Iwasaki 氏が報告し、JPCERT/CC を介してJVN#01719116として2026年5月28日に国内公開されました。

問題はログイン後のリダイレクト先を決める next クエリパラメータの検証が甘く、/login?next=///example.com のようなURLを踏ませると、自社のJupyter画面だと信じてログインボタンを押した利用者が、攻撃者の用意した偽サイトに連れて行かれてしまう点にあります。CVSSは v3.1 で 6.1（中）、v4.0 で 6.3（中）。一見地味ですが、攻撃ベクトルはネットワーク・認証不要・ユーザー操作のみ。ターゲットになるのは、機微なデータ・モデル・社内認証情報を握る研究者層です。

影響は Jupyter Server 2.17.0以前のすべてのバージョンに及び、修正版は2.18.0。これに連動してJupyterLab や Jupyter Notebook 7 など、Jupyter Server を内部で使うフロントエンド一式も同じ穴を抱えていました。JupyterHub で配信される多人数環境のユーザーサーバも例外ではありません。

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 実験環境

2026年4月リリースのNotebook v7.5.6を含め、最近のリリースは内部で 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.18.0 以降にバージョンを上げることです。PyPIの最新版と環境のバージョンが揃っているかを確認してから、JupyterLab や Notebook を起動し直す流れになります。

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

報告は日本のCyber Defense Institute

本件の報告者は、東京の独立系セキュリティ企業 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（協調的脆弱性開示）の手順を踏んだ綺麗な流れです。

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

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

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

• jupyter_server を 2.18.0 以降に更新する
• 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 にも自動で波及すること、研究者・大学アカウントの認証情報という価値の高いターゲットに直結することを踏まえると、運用者・利用者ともに早めの更新が現実的な落としどころです。

そして、こうした「縁の下のOSS」の脆弱性を日本の研究者がきちんと拾い、Jupyter コアチームとの調整を経て JVN にも載せていく取り組み自体が、国内セキュリティコミュニティのひとつの成果でもあります。手元の pip list を見て、jupyter_server の行が 2.17.0 以下のまま止まっていたら、いまこの記事を閉じる前にバージョンを上げておきたいところです。

参照元

• ▸ JVN#01719116 — Jupyter Serverにおけるオープンリダイレクトの脆弱性（JPCERT/CC、2026年5月28日）
• ▸ GitHub Security Advisory — GHSA-qh7q-6qm3-653w（jupyter-server、2026年5月5日）
• ▸ NVD — CVE-2025-61669
• ▸ jupyter_server/auth/login.py（修正後のコード）
• ▸ jupyter-server — PyPI
• ▸ Cyber Defense Institute, Inc.（報告者所属）
• ▸ OWASP — Open Redirect
• ▸ CWE-601: URL Redirection to Untrusted Site