< ブログ一覧に戻る

Marimo OSS PythonノートブックのRCE:公開から悪用まで10時間未満

清水 孝郎
Marimo OSS PythonノートブックのRCE:公開から悪用まで10時間未満
執筆者
清水 孝郎
Marimo OSS PythonノートブックのRCE:公開から悪用まで10時間未満
Published:
April 9, 2026
この記事の内容
シスディグによるファルコフィード

Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

さらに詳しく
Green background with a circular icon on the left and three bullet points listing: Automatically detect threats, Eliminate rule maintenance, Stay compliant, with three black and white cursor arrows pointing at the text.

本文の内容は、2026年4月9日に Sysdig Threat Research Team が投稿したブログ(https://www.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours)を元に日本語に翻訳・再構成した内容となっております。

2026年4月8日、オープンソースのリアクティブPythonノートブックプラットフォームであるmarimoにおいて、重大な脆弱性が公開されました。現在、GHSA-2679-6mx9-h9xcとして追跡されており、ターミナルWebSocketエンドポイントに存在する事前認証のリモートコード実行(RCE)脆弱性です。この脆弱性により、攻撃者は単一のWebSocket接続を通じて、公開されている任意のmarimoインスタンス上で完全な対話型シェルを取得することが可能となります―認証情報は不要です。本稿執筆時点では、CVE番号はまだ割り当てられていません。

脆弱性アドバイザリの公開からわずか9時間41分後、Sysdig 脅威リサーチチーム(TRT)は、実環境における最初の悪用試行を観測しました。また、完全な認証情報窃取のオペレーションが3分未満で実行されました。当時、公開された概念実証(PoC)コードは存在していませんでした。攻撃者はアドバイザリの説明から直接実用的なエクスプロイトを構築し、未認証のターミナルエンドポイントに接続して、侵害された環境の手動探索を開始しました。同様の事例は最近、Langflowの脆弱性(CVE-2026-33017)でも発生しており、公開されたエクスプロイトがない状態で20時間以内に悪用されました。このmarimoの脆弱性は、その時間を半分未満に短縮しています。

この事例で特に注目すべき点は、その標的です。Marimoはエンタープライズソフトウェアにおいて広く知られた名前ではありません。GitHubスター数は約20,000であり、歴史的に大規模なスキャンキャンペーンの対象となってきたLangflow(145,000以上)やn8n(75,000)といったプラットフォームと比べると、その規模はごく一部に過ぎません。Sysdig TRTが観測した悪用の速度は、脅威アクターが著名な標的だけでなく広範にアドバイザリを監視しており、公開から数時間以内にニッチなソフトウェアの脆弱性でさえ武器化できることを示唆しています。また、脆弱性アドバイザリの説明を解析し、実用的なエクスプロイトを構築し、作戦を加速するためにAIが使用されている可能性も示しています。

アドバイザリ公開から数時間以内に、Sysdig TRTは複数のクラウドプロバイダー上で脆弱なmarimoインスタンスを実行するハニーポットノードを展開しました。以下に詳細を示すTRTが取得したアクティビティは、単一の攻撃者が初期アクセスから認証情報の窃取に至るまでを、わずか数分でどのように進めたかを明確に示しています。

タイムライン

時刻(UTC)

イベント

4月8日 21:50

GitHub上でアドバイザリ GHSA-2679-6mx9-h9xc が公開

4月9日 07:31

最初の悪用試行を観測(49.207.56.74 から)

4月9日 07:44

攻撃者が認証情報を含む .env ファイルを外部に流出させる

4月9日 08:57

攻撃者が2回目の悪用セッションのために再訪

アドバイザリの公開から最初の悪用までの間隔は9時間41分でした。初回の攻撃時点では、GitHubや主要なエクスプロイトリポジトリ上に公開されたPoCコードは存在していませんでした。アドバイザリ自体には、攻撃者が実用的なエクスプロイトを構築するのに十分な詳細が含まれていました。すなわち、脆弱なエンドポイントのパス(/terminal/ws)と、アプリケーション内の他のWebSocketエンドポイントとは異なり認証が欠如しているという点です。

脆弱性について

Marimoは、Jupyterの現代的な代替として設計されたオープンソースのリアクティブなPythonノートブックです。ノートブックを純粋なPythonファイルとして保存し、リアクティブな実行をサポートし、インタラクティブなWebアプリケーションとしてデプロイすることが可能です。主流のノートブックプラットフォームより規模は小さいものの、marimoには活発なコミュニティがあり、データサイエンスや研究のワークフローで利用されています。

GHSA-2679-6mx9-h9xc(CVSS v4.0: 9.3、Critical)は、marimoのバージョン0.20.4以前における /terminal/ws WebSocket エンドポイントに影響します。この脆弱性は単純です。このエンドポイントは対話型のPTY(擬似端末)シェルを提供しますが、認証検証が完全に欠如しています。アプリケーション内の他のWebSocketエンドポイント(例:/ws)は、接続を受け入れる前に正しくvalidate_auth() を呼び出しています。一方で、ターミナルエンドポイントはこのチェックを完全にスキップしており、未認証の任意のユーザーからの接続を受け入れ、marimoプロセスの権限で実行される完全な対話型シェルを付与します。

この修正は、PR #9098(https://github.com/marimo-team/marimo/pull/9098)を通じてバージョン0.23.0でリリースされました。

marimoのユーザーベースが比較的小さいにもかかわらず、この脆弱性が魅力的であった理由はいくつかあります。

  • 認証は不要です。エクスプロイトは単一の WebSocket 接続のみで成立します。認証情報もトークンもセッション管理も不要です。
  • 対話型シェルへのアクセス。多くのRCE脆弱性ではコマンドごとにペイロードを作成する必要がありますが、これは持続的な対話型ターミナルを提供します。攻撃者はSSHのようにコマンドを入力し、リアルタイムで出力を確認できます。
  • 悪用は極めて容易です。アドバイザリにはどのエンドポイントが影響を受け、なぜ脆弱であるかが正確に記載されています。/terminal/ws に WebSocket 接続できる攻撃者は誰でもシェルを取得できます。作成すべきペイロードも、整形すべきインジェクションも、正しく行うべきエンコーディングもありません。攻撃者はそのまま侵入できます。
  • 価値の高い環境です。ノートブックプラットフォームには、データベース接続、APIキー、クラウド認証情報、データセットへのアクセスなどが設定されています。1つのインスタンスを侵害することで、接続されたインフラへの横展開が可能になる場合があります。

観測された内容

アドバイザリ公開後の最初の12時間において、当社のハニーポット群を標的とした1つの送信元IPからのエクスプロイト活動を記録しました。さらに、125のユニークなIPが偵察(ポートスキャン、HTTPプロービング)を実施しましたが、WebSocketターミナルの脆弱性の実際の悪用に進んだのは1つのみでした。

セッション 1: PoC 検証 (7:31 UTC)

攻撃者は、europe-west1-b にあるハニーポットのGCPノード上の /terminal/ws WebSocketエンドポイントに接続し、直ちにスクリプト化された検証シーケンスを実行しました。

echo '---POC-START---'
id
echo '---POC-END---'

マーカー文字列(—POC-START— および —POC-END—)と、テストコマンドとして id を使用していることから、これは手動入力ではなく、構造化されたPoCスクリプトであることが分かります。攻撃者は手動での探索に時間を費やす前に、コード実行が可能であることを確認しています。このセッションは、攻撃者が切断するまで9秒間続きました。

セッション 2: 手動偵察 (07:33 UTC)

2 分後、攻撃者は再接続し、手動による調査を開始しました。

pwd         → /app/marimo
whoami      → marimo
ls          → marimo  logs  data  .env  docker-compose.yml  celerybeat-schedule

攻撃者は、cd ../、cd logs、cd ~/.ssh を使用してファイルシステム内の移動を試み、それぞれの試行後に ls を実行して現在位置を確認しました。また、ネットワークインターフェースを列挙するために ipaddr(おそらく ip addr の意味)も試みました。これらの偵察プロセスは、タイムラインや実行された手順から判断して、AIによるものではなく手動で行われたものと見られます。

セッション 3: 認証情報の窃取 (07:43 UTC)

6 分間待機した後、攻撃者は再接続し、焦点を絞った認証情報収集セッションを行いました。彼らはすぐにディレクトリを一覧表示し、.env ファイルを標的にしました。

ls          → marimo  logs  data  .env  docker-compose.yml  celerybeat-schedule
cat .env    → HOME=/app/marimo
               PATH=/usr/local/bin:/usr/bin:/bin
               HOSTNAME=prod-app-e29e
               AWS_DEFAULT_REGION=us-east-1
               AWS_ACCESS_KEY_ID=AKIA01FB...

ハニーポットは、.env の応答において、AWSアクセスキーやアプリケーションのシークレットを含む現実的な偽の認証情報を返しました。実際の環境では、これは攻撃者が侵害されたノートブックインスタンスからクラウドアカウント、データベース、サードパーティAPIへと横展開するために必要なデータそのものです。

その後、攻撃者はディレクトリ内のすべてのファイルを系統的に読み取ろうとしました。

cat data
cat docker-compose.yml
cat celerybeat-schedule
cat marimo
cat logs

また、SSH キーも検索しました。

ls ~
ls ~/
ls ~/.ssh
cd ~/ssh
cd ~/.ssh

セッションは、攻撃者が07:45 UTCに exit を実行して終了しました。これは、3分未満で実行された完全な認証情報窃取オペレーションです。

セッション 4: 再訪問 (8:57 UTC)

1時間以上後、攻撃者は再び戻り、PoC検証スクリプト(echoによるマーカー出力+id)を再実行した後、再接続して .env ファイルを再度読み取りました。また、history を実行しており、同じインスタンス上で他の攻撃者が活動していないかを確認していた可能性があります。このセッションは09:04 UTCに終了しました。

攻撃者プロフィール

悪用のパターンは、自動化されたスキャナではなく、体系的に行動するオペレーターの存在を示しています。

  • スクリプト化されたPoC:マーカーで区切られた検証ステップは、攻撃者がスクリプトを実行して脆弱性を確認し、その後に手動操作へ切り替えるワークフローを示唆しています。
  • 目的の集中:攻撃者は .env の認証情報やSSHキーを直接狙いました。永続化の設定や暗号通貨マイナーの展開、追加ツールのダウンロードは試みていません。
  • 複数セッション:攻撃者は90分間に4回接続しており、各セッションの間に間隔があります。これは、ターゲットのリストを順に処理し、結果を確認するために戻る人間のオペレーターの行動と一致します。

防御側にとっての意味

アドバイザリの公開から最初の悪用までの9時間41分という時間差は、過去数年にわたって加速してきた傾向を引き続き示しています。83,000件を超えるCVEのデータを追跡しているZero Day Clockプロジェクトによれば、悪用までの時間の中央値は2018年の771日から、近年ではわずか数時間にまで急減しています。2023年までには、悪用された脆弱性の44%が公開から24時間以内に武器化されていました。GHSA-2679-6mx9-h9xcに関するSysdig TRTの観測は、まさにこの傾向に当てはまります。

この事例を際立たせているのは、その標的です。MarimoはLangflowでもJenkinsでもGitLabでもありません。GitHubスター数は145,000ではなく20,000です。現在のところ、CISAの既知の悪用された脆弱性(KEV)カタログにも掲載されていません。大規模なスキャンキャンペーンの一般的な標的でもありません。それにもかかわらず、重大なアドバイザリが公開されてから10時間以内に、攻撃者は実用的なエクスプロイトを構築し、脆弱な組織が手動でパッチを適用するよりはるかに速く、公開されたインスタンスから認証情報を積極的に収集していました。

これは、組織が自らの曝露をどのように評価するかに対して示唆を与えます。

  • ニッチまたは人気の低いソフトウェアが安全であるとは限りません。攻撃者は広く普及しているプラットフォームのみを標的にするという前提は誤りです。インターネットに公開されているアプリケーションで重大なアドバイザリが存在するものは、その人気に関係なくすべて標的となります。
  • アドバイザリの詳細は悪用を可能にします。GHSA-2679-6mx9-h9xcは、悪用にリバースエンジニアリングを必要としませんでした。アドバイザリにはエンドポイント名、認証チェックの欠如、影響を受けるバージョンが明記されていました。このレベルの詳細は防御側にとって不可欠である一方、攻撃者にとっても同様に有用です。
  • CVEがないことは、悪用がないことを意味しません。本稿執筆時点では、この脆弱性にはCVE番号が割り当てられていませんが、すでに悪用は発生しています。CVEベースのスキャンやアラートに依存している組織では、このアドバイザリをまったく検知できなかった可能性があります。
  • 対話型シェルは前提を変えます。多くの自動化されたRCE悪用は、リクエストごとに単一のコマンドを実行します。しかし、WebSocketターミナルは持続的で対話的なアクセスを提供します。これにより、攻撃者はコマンドごとに新しいペイロードを作成する必要がなくなり、侵入後の操作がより迅速かつ包括的に行えるようになります。

セキュリティ侵害の指標

ソース IP

IP

場所

活動内容

49.207.56.74

インド(IN)

WebSocketターミナルの悪用、認証情報の窃取

注:送信元IPは、実際の攻撃者の所在ではなく、プロキシまたはVPNのエンドポイントである可能性があります。

推奨事項

  • marimoを直ちにバージョン0.23.0以降に更新してください。アップグレードが不可能な場合は、/terminal/ws エンドポイントへのネットワークアクセスを制限するか、ターミナル機能を完全に無効化してください。
  • 公開アクセス可能であった marimo インスタンス上の環境変数、.env ファイル、およびシークレットを監査してください。予防措置として、AWS認証情報、APIキー、データベースパスワード、およびSSHキーをローテーションしてください。
  • ファイアウォールルールまたは認証付きのリバースプロキシを使用して、marimo インスタンスへのネットワークアクセスを制限してください。ノートブックプラットフォームは、認証レイヤーなしでインターネットに直接公開すべきではありません。
  • 想定外の送信元から /terminal/ws へのWebSocket接続がないか監視してください。ターミナル機能の正当な利用は、内部ネットワーク上の認証済みユーザーに限定されるべきです。
  • 環境内のノートブックおよびデータサイエンスツールを棚卸ししてください。marimo、Jupyter、およびその他のノートブックツールのようなプラットフォームは、標準的なセキュリティレビューのプロセス外で研究チームによって導入されることが多く、広範なクラウド認証情報を伴って稼働している可能性があります。

まとめ

GHSA-2679-6mx9-h9xcは、悪用までの時間の短縮が最も人気のあるソフトウェアに限られたものではないことを示しています。GitHubスター数20,000のPythonノートブックにおける重大な脆弱性が、公開されたPoCもなく、CVE番号も割り当てられていない状態で、10時間未満で武器化され、さらに3分未満で完全な認証情報窃取オペレーションが実行されました。攻撃者に必要だったのは、アドバイザリの内容とWebSocketクライアントだけでした。

防御側にとっての教訓は、アドバイザリの監視はCVEデータベースや著名なプロジェクトに限定すべきではないということです。インターネットに公開されているアプリケーションで重大な脆弱性が公表された場合、そのインストール規模に関係なく、公開から数時間以内に標的となる可能性があります。

パッチ適用までの猶予が日単位ではなく時間単位で測られる状況においては、ランタイム検知、ネットワークセグメンテーション、そして迅速な認証情報のローテーションが、依然として最も有効な対策です。

About the author

Cloud detection & response
Cloud Security
Kubernetes & Container Security
Security for AI

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう