本文へ移動
English version →
重大 9.8 急ぎ度: 至急

Mercury、認証なしで任意コード実行の恐れ 3.2.6で修正

Python製のノートブック公開ツール Mercury に、ログインなしで外部からサーバー上の任意のコードを実行されるおそれのある脆弱性が見つかりました。初期設定のままネットワークに公開している環境が対象で、3.2.6 で修正されています。該当する場合は 3.2.6 以降へ更新し、更新までは外部からのアクセスを制限してください。

CVE-2026-111058 公開 生成 AI で作成
画像は生成 AI で作成したイメージです

急ぎ度: 至急

認証なしでネットワーク越しに悪用でき、初期設定のまま動かしている環境がそのまま対象になり、深刻度も CVSS 9.8 と最高水準だからです。

関係があるか

Mercury を社内外のサーバーやコンテナで動かしている組織が対象です。特にトークンやパスワードを設定せず(初期設定のまま)、他の端末やインターネットから接続できる状態の環境は影響を受けます。

製品影響を受ける版直った版
mercury(PyPI パッケージ、GitHub の mljar/mercury) 3.2.6 より前のすべての版(3.2.4 でも該当が確認されています) 3.2.6

確かめ方

  1. 1Mercury を動かしているサーバーやコンテナで版を確認します。pip show mercury の Version が 3.2.6 未満なら修正前の版です。
  2. 2起動時に --token オプションか環境変数 MERCURY_TOKEN を指定しているか、起動スクリプト、systemd の設定、Dockerfile、compose ファイルで確認します。指定がなければ認証なしの初期設定で動いています。
  3. 3そのサーバーのポートに、どのネットワークから接続できるかを確認します。社内全体やインターネットに公開されていれば、影響の範囲が広がります。
  4. 4ノートブックを共有する目的で、部署や個人が独自に立てた Mercury がないかも洗い出してください。情報システム部門が把握していないことがあります。

何が起きたか

Mercury は、Jupyter のノートブックをそのまま Web アプリとして公開できるツールです。初期設定ではログインなしで誰でも使える作りになっており、危険な操作につながる入口を個別に塞ぐことで安全を保とうとしていました。ところが、ノートブックを動かすための入口が塞がれておらず、ネットワーク越しに接続できる人なら誰でも、サーバー上で好きなプログラムを動かせる状態でした。実行されるプログラムはサーバーを動かしているユーザーの権限で動くため、サーバーの乗っ取りにつながります。

技術的には、Mercury は /lab や /api/terminals など一部の経路を拒否リスト方式で遮断しています。しかし /api/kernels は、ノートブックを実行するために Mercury 自身が必要とするため遮断できません。カーネルとの通信経路にあるコード実行要求(execute_request)も、アイドルタイムアウトの記録以外の検査をしていませんでした。分類は CWE-862(認可の欠如)です。

過去に同じ製品で、拒否リストの記述ミスにより /api/terminals が突破される問題(GHSA-f8c7-rwf9-fmgm)が修正されています。今回の問題はそれとは別で、その修正を適用済みの 3.2.4 でも、今回の問題でコード実行できることが報告者により確認されています。拒否リストに項目を足すだけでは直せない設計上の問題とされています。

攻撃の流れ

  1. 1

    到達できる

    認証なし(初期設定)の Mercury に、攻撃者がネットワーク経由で接続できる状態です。

  2. 2

    実行環境を作る

    拒否リストに含まれない `/api/kernels` を使い、ログインなしでコードの実行環境を作成します。

  3. 3

    コードを送る

    実行環境との通信経路に、攻撃者が用意した Python のコードを送ります。

  4. 4

    サーバーで実行

    送られたコードが検査されないまま、Mercury を動かしているユーザーの権限で実行されます。

  5. 5

    乗っ取り

    ホストやコンテナ内のデータ、認証情報、接続先の社内システムまで影響が及ぶ可能性があります。

公開されている情報をもとにした流れの例です。

どう悪用されるか

悪用に必要なのは、Mercury のサーバーにネットワークで接続できることだけです。ログインは不要で、管理者や利用者に操作を促す必要もありません。複雑な条件も不要で、報告者は再現手順(PoC)を公開情報に含めています。そのため、悪用のハードルは低いと考えるべきです。

悪用されると、Mercury を動かしているユーザーの権限で、サーバー上のファイルの読み書きや外部への通信など任意の処理を実行されます。報告者は、サーバー上でコマンドを実行できることと、ファイルを書き込めることを実機で確認しています。サーバーやコンテナ全体の乗っ取りに加え、そこから触れられるデータや認証情報(環境変数、接続先のデータベース、クラウドの鍵など)も危険にさらされます。

実際の攻撃での悪用が確認されたという情報は、現時点では公表されていません。ただし、手順が公開されている点と、初期設定のまま動かしているだけで該当する点から、悪用が始まる前に対応しておくのが安全です。

今すぐやること

  1. 1

    Mercury の稼働状況を洗い出す

    サーバー、コンテナ、開発用の環境まで含めて Mercury を探し、版と、トークン設定の有無、公開範囲を一覧にします。

    pip show mercury
  2. 2

    3.2.6 以降へ更新する

    mercury を 3.2.6 以降に更新し、サービスを再起動します。コンテナの場合は、更新したイメージを作り直して入れ替えます。3.2.4 など過去の修正を当てた版でも、今回の問題は残っています。

  3. 3

    更新までのあいだ公開範囲を絞る

    インターネットや広い社内ネットワークに公開されている場合は、ファイアウォール、VPN、認証付きのリバースプロキシなどで、接続できる相手を必要な人だけに絞ります。すぐに更新できない環境では、サービスの停止も検討してください。

  4. 4

    認証設定を見直す

    更新後も、認証なしの運用は避けてください。トークンの指定(--token または MERCURY_TOKEN)の扱いは、Mercury の公式の告知とドキュメントで確認し、アクセス制御を前段に置く運用も検討してください。

  5. 5

    侵入の痕跡を確認する

    公開状態で動かしていた場合は、リバースプロキシやアクセスログで、心当たりのない相手から /api/kernels へのリクエストがないかを確認します。あわせて、サーバー上の不審なプロセスや新しいファイル、外部への見慣れない通信も調べます。兆候があれば、そのサーバーから触れられる認証情報や鍵の入れ替えを検討してください。

すぐ更新できないとき

修正版をすぐ適用できない場合は、Mercury のポートに接続できる相手をファイアウォールや VPN、認証付きのリバースプロキシで必要最小限に絞るか、サービスを止めてください。トークン設定による認証が有効かどうかは、公式の告知とドキュメントで確認し、確認が取れるまでは、ネットワーク側の制限を主な対策としてください。

背景

Mercury は、データ分析のノートブックを、コードを書けない人でも使える Web アプリとして共有するためのツールです。裏では JupyterLab のサーバーが動いており、ノートブックのコードを実行する機能そのものが、サーバー上で任意のプログラムを動かせる機能でもあります。このため、利用者を認証して絞り込む仕組みが安全の前提になります。

この種のツールでは、認証なしで公開されたまま放置され、外部から勝手にコードを実行されるという問題が以前から繰り返し指摘されてきました。拒否リスト方式は、危険な入口を一つ塞いでも、別の入口が残りやすい点が弱みです。今回も、過去の修正を適用したあとに別の入口が見つかった形で、入口ごとの遮断に頼るのではなく、認証を既定で必須にするといった設計の見直しが対策の軸になります。

よくある質問

Q.以前の脆弱性(GHSA-f8c7-rwf9-fmgm)の修正を適用済みですが、安全ですか。
A.安全ではありません。過去の修正は /api/terminals の問題を直すもので、今回の /api/kernels の問題は別です。3.2.4 でも今回の問題でコード実行できることが確認されており、3.2.6 以降への更新が必要です。
Q.社内ネットワークからしか接続できない場合も、対応は必要ですか。
A.必要です。接続できる人なら誰でも悪用でき、社内の端末が1台でも乗っ取られれば足がかりにされます。インターネットに公開しているより緊急度は下がりますが、早めに更新してください。
Q.すでに攻撃を受けたかどうかは、どう確かめればよいですか。
A.リバースプロキシやアクセスログで /api/kernels への不審なリクエストを確認し、サーバー上の見覚えのないファイルやプロセス、外部への不審な通信も調べてください。ただし、攻撃されても痕跡が残らない場合があるため、公開状態だった環境では、被害を受けた可能性も前提に鍵や認証情報の入れ替えを検討してください。

まだ分かっていないこと

  • 実際の攻撃で悪用されたという情報は、現時点で公表されていません。
  • 3.2.6 での具体的な修正内容と、トークン設定を含む推奨の運用方法は、ベンダーの告知(GitHub のセキュリティアドバイザリとリリースノート)で確認してください。

この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。

影響パッケージ

種類パッケージ影響を受ける版直った版
pip mercury
3.2.6 未満
3.2.6
PyPI mercury
3.2.6 未満
3.2.6
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. Prior to 3.2.6, default tokenless deployments allow anonymous clients to create Jupyter kernels and send execute_request messages containing arbitrary Python. The endpoint blocklist does not cover /api/kernels, and the websocket wrapper previously tracked idle activity without authorizing executable messages. This issue is fixed in version 3.2.6.

出典: GitHub Security Advisories (Global) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく