MarimoのCVE-2026-39987は、未認証でターミナルWebSocketからシェルに到達できる重大なRCE脆弱性だ。CISA KEV追加、公開後9時間41分での悪用観測、影響環境、更新・露出遮断・資格情報ローテーションまで実務対応を整理する。
AIノートブックが「開発用だから安全」とは言えなくなった
Pythonのリアクティブノートブック環境 Marimo に見つかった CVE-2026-39987 は、AI・データ分析基盤を運用するチームにとって見過ごせないニュースだ。GitHub Advisory では 2026年4月8日に公開され、CISA は 2026年4月23日に Known Exploited Vulnerabilities（KEV）カタログへ追加した。
問題は、Marimo のターミナル WebSocket エンドポイント /terminal/ws が認証検証を欠いていたことにある。外部から到達できる環境では、未認証の攻撃者が完全な PTY シェルを取得し、Marimo プロセスの権限で任意コマンドを実行できる可能性がある。
Sysdig Threat Research Team は、アドバイザリ公開から 9時間41分 で最初の悪用を観測し、攻撃者が 3分未満 で .env から認証情報を抜き取る流れを確認した。公開PoCがない段階でも、攻撃者はアドバイザリ本文だけを読んで実用的な攻撃を組み立てていたことになる。
- 対象製品: Marimo
- 影響バージョン: 0.20.4 以下
- 修正版: 0.23.0
- 脆弱性タイプ: 認証前リモートコード実行、Missing Authentication for Critical Function
- 影響箇所: ターミナル WebSocket エンドポイント
/terminal/ws - NVD CVSS 3.1: 9.8 Critical
- CISA KEV追加日: 2026年4月23日
- CISA期限: 2026年5月7日
CVE-2026-39987で何が起きたのか
Marimo は、Jupyter Notebook に近い使い方ができるオープンソースのPythonノートブック環境だ。ノートブックを純粋なPythonファイルとして扱い、データ分析、研究、AIアプリケーションの試作、インタラクティブなWebアプリ公開に使われる。
CVE-2026-39987 の根本原因は、ターミナル機能を提供する WebSocket エンドポイントの認証漏れだ。GitHub Advisory によれば、通常の WebSocket エンドポイントでは validate_auth() による認証検証が行われる。一方で、問題の /terminal/ws は実行モードとターミナル対応状況だけを確認し、認証チェックを行わずに接続を受け入れていた。
これは単なる「ログイン画面のバグ」ではない。接続先がターミナルであるため、成功時の影響はアプリケーション内の操作に留まらない。Marimo が動いているコンテナ、VM、サーバー上で、Marimo プロセス権限のシェルを触れる状態になる。
本記事では、攻撃再現に使えるコードや接続手順は記載しない。重要なのは、特定のWebSocketに未認証で到達できること自体が、ノートブック環境ではクラウド資格情報や研究データの流出につながる、という構造を理解することだ。
なぜAIノートブックのRCEは危険なのか
ノートブック環境は、普通のWebアプリより危険な情報を近くに置きがちだ。データサイエンスやAI開発では、サンプルコード、検証用データ、クラウドAPIキー、LLMプロバイダのAPIキー、DB接続文字列が同じ作業ディレクトリに集まりやすい。
Sysdig の観測でも、攻撃者は侵入後すぐに .env を読み、AWSアクセスキーやアプリケーションシークレットのような資格情報を狙っていた。これは偶然ではない。ノートブックは「計算する場所」であると同時に、「外部サービスへつなぐための鍵が置かれやすい場所」でもある。
| 置かれやすい情報 | 侵害時に起きること |
|---|---|
.env や設定ファイル | APIキー、DBパスワード、クラウドキーの流出 |
| 学習データ・分析データ | 個人情報、研究データ、業務データの流出 |
| ノートブック内のコード | 内部API、データ処理ロジック、業務ノウハウの露出 |
| SSHキー・クラウド認証情報 | 横展開、クラウドリソース操作、追加侵害 |
この意味で、Marimo の脆弱性は CyberLens の 管理プレーンセキュリティ と同じ文脈で見るべきだ。ノートブック自体は開発ツールでも、そこにシェル、認証情報、クラウド接続が集まると、実質的には開発・分析基盤の管理プレーンになる。
公開から10時間未満で悪用された理由
今回のニュースで特に重要なのは、悪用までの速さだ。Sysdig は、GitHub Advisory が 2026年4月8日 21:50 UTC に公開され、2026年4月9日 07:31 UTC に最初の悪用を観測したとしている。差は 9時間41分。さらに 07:44 UTC には .env の窃取が確認された。
ここで注目すべき点は、当時公開PoCがなかったことだ。攻撃者はGitHub Advisoryに書かれた「どのエンドポイントが認証を欠いているか」という説明だけから、攻撃可能な形へ落とし込んだ。
この流れは、以前取り上げた LangflowのRCE脆弱性 とよく似ている。Langflowでは公開から約20時間で悪用が観測されたが、Marimoではそれより短い時間で悪用が始まった。AI開発ツールやデータ分析基盤も、いまや「ニッチだから狙われにくい」とは言えない。
CISA KEV への追加は、実際の悪用が確認された脆弱性であることを示す強いシグナルだ。ただし今回のように、KEV入りの前から攻撃が始まっているケースもある。公開済みの重大アドバイザリを見つけた時点で、外部露出の有無を先に確認する運用が必要になる。
影響を受ける環境と優先順位
すべての Marimo 利用が同じ危険度になるわけではない。最優先で見るべきなのは、Marimo をネットワーク越しに公開している環境だ。
| 優先度 | 条件 | 理由 |
|---|---|---|
| 最優先 | Marimo 0.20.4 以下をインターネット公開している | 未認証RCEの条件に直結する |
| 最優先 | DockerやVM上でMarimoをrootまたは高権限で動かしている | シェル取得時の影響が大きい |
| 高 | .env、クラウドキー、LLM APIキーを同一環境に置いている | 侵害後すぐ資格情報窃取につながる |
| 高 | 研究チームや個人が標準のセキュリティレビュー外で運用している | 資産台帳・監視・更新から漏れやすい |
| 中 | 社内限定だがVPNや踏み台だけに依存している | 端末侵害後の横移動で悪用され得る |
特にAI開発の現場では、「とりあえず検証用に立てたノートブック」がそのまま残ることがある。PoC、研究用、社内デモ用というラベルは、攻撃者には関係ない。外部から到達でき、認証が弱く、資格情報が置かれていれば、十分に価値のある標的になる。
管理者が今すぐやるべきこと
今回の対応は、単純なパッケージ更新だけでは足りない。すでに悪用が観測されているため、脆弱性管理とインシデント対応を同時に進める必要がある。
1. Marimoのバージョンと公開範囲を棚卸しする
まず Marimo 0.20.4 以下が残っていないか確認する。対象は本番だけではない。検証環境、研究環境、個人用VM、Kubernetes上の一時Pod、共有GPUサーバー、社内デモ環境まで含めて見る。
あわせて、Marimoがどこから到達できるかを確認する。インターネット公開、社内限定、VPN配下、リバースプロキシ配下、認証付きプロキシ配下では、リスクが大きく変わる。
2. 0.23.0以上へ更新する
GitHub Advisory と NVD は、修正版を 0.23.0 としている。影響対象は 0.20.4 以下だ。該当環境がある場合は、Marimoを更新し、コンテナイメージや依存関係ロックファイルも合わせて更新する。
重要なのは、起動中のプロセスまで確認することだ。パッケージだけ更新しても、古いコンテナや古い仮想環境が起動し続けていれば、脆弱なまま残る。
3. 外部露出を閉じる
ノートブック環境は、原則としてインターネットへ直接公開しない方がよい。必要な場合でも、SSO、MFA、ZTNA、認証付きリバースプロキシ、送信元制限を組み合わせる。
「研究チームだけが使うから」「URLを知っている人しか来ないから」という前提は危うい。アドバイザリ公開後のスキャンは速く、今回のように10時間未満で実際の悪用に到達する。
4. 資格情報をローテーションする
該当バージョンを公開していた場合、.env やホームディレクトリ、作業ディレクトリに置かれていた資格情報は漏れた前提で扱う。特に次の情報は優先して無効化・再発行したい。
- LLM APIキー
- AWS / Azure / Google Cloud のアクセスキー
- DB接続文字列
- GitHubやGitLabのトークン
- SSHキー
- 外部SaaSのWebhookシークレット
この対応は面倒だが、侵害後に攻撃者が狙うのはアプリそのものよりも、そこから先へ進むための鍵だ。LiteLLM汚染事件でも、AI開発ツール周辺の資格情報がどれだけ大きな攻撃面になるかが示されている。
5. ログとプロセス履歴を確認する
Marimoサーバーのアクセスログ、リバースプロキシログ、コンテナログ、EDRログを確認し、外部からの不審なWebSocket接続や、通常運用にないシェル操作の痕跡を探す。
確認したいのは、単に「攻撃が成功したか」だけではない。.env、SSHキー、クラウド設定ファイル、履歴ファイルへのアクセスがあったか。外部への不審な通信があったか。コンテナ内に追加ツールが置かれていないか。ここまで見て、ようやく封じ込め判断ができる。
このニュースが示すAI開発基盤の教訓
CVE-2026-39987 は、Marimo固有のバグであると同時に、AI開発基盤全体への警告でもある。Jupyter、Langflow、Marimo、LiteLLM、n8nのようなツールは、試作や自動化を速くする一方で、クラウド資格情報、モデルAPIキー、データセット、社内APIへの接続を一箇所に集めやすい。
開発者にとって便利な「ブラウザから触れるターミナル」は、攻撃者にとっても便利だ。認証が抜けていれば、それは管理画面の脆弱性というより、インターネット越しのシェル公開に近い。
AI時代の開発基盤では、次の3点を標準にしたい。
- ノートブックやLLMツールも資産台帳に載せる
- 検証環境でも外部公開時はSSO/MFA/送信元制限を必須にする
.envに長期キーを置かず、短命な認証情報やSecret Managerを使う
「研究用だから」「一時的だから」という例外は、攻撃者のスキャンには通用しない。今回の9時間41分という数字は、その現実をかなり冷たく示している。
まとめ
Marimo の CVE-2026-39987 は、0.20.4 以下に存在する認証前RCE脆弱性だ。ターミナル WebSocket の認証漏れにより、外部から到達できる環境では未認証でシェルを取得される可能性がある。CISA KEV に追加されたことで、通常の更新計画ではなく緊急対応として扱うべき段階に入った。
特に重いのは、公開から9時間41分で悪用が観測され、3分未満で資格情報窃取まで進んだ点だ。AIノートブックやデータ分析基盤は、開発環境であってもクラウドやSaaSへつながる鍵を持っている。だからこそ、更新、露出遮断、ログ確認、資格情報ローテーションをセットで進めたい。
次に読むなら、管理プレーンセキュリティ と LangflowのRCE脆弱性 を合わせて確認すると、AI開発ツールをどう守るべきかが立体的に見えてくる。
