攻撃者がmarimoの未認証RCE「CVE-2026-39987」を自作ツールで悪用 — WebSocket接続から8秒でSSH踏み台に到達（Sysdig分析）

要点

• セキュリティ企業Sysdigの脅威研究チーム（TRT）は2026年9月11日、Pythonノートブック「marimo」の未認証リモートコード実行（RCE）脆弱性「CVE-2026-39987」を悪用した攻撃者の分析結果を公表した。
• この攻撃者はAIエージェントを使わずに自作したPythonツールを使い、WebSocket接続でシェルを取得してから、AWS Secrets ManagerでSSH秘密鍵を取り出し、踏み台ホストへSSH認証するまでを8秒で完了させた。
• Sysdigは、AIを使う攻撃者と熟練した人手の攻撃者は同じ速度の攻撃に到達し得ると指摘する。検知では、コマンドの書き方ではなく攻撃の連鎖（チェーン）の形に着目すべきだとしている。

何が起きたのか

Sysdigの脅威研究チーム（TRT）は2026年9月11日、Pythonノートブック「marimo」の脆弱性CVE-2026-39987を悪用した攻撃者についての分析を公表した。Sysdigはこの脆弱性を悪用する複数の攻撃者を継続して観測しており、今回の報告はそのうちの1人についてのものだ。

Sysdigが観測した攻撃者の動きは、次のとおりだ。

• 攻撃者は9時間のセッションで850以上の対話コマンドを実行した。
• 最初のWebSocket接続は協定世界時（UTC）12時52分18秒。攻撃者はまず、ホストと同じネットワーク（RFC1918の/24）に対するTCPスキャンを行った。
• 最も速い連鎖では、18時57分22秒に新しいWebSocketセッションを開始し、18時57分30秒に踏み台ホストへのSSH認証が確認された。接続開始から認証までの時間は8秒で、この間にAWS Secrets ManagerへのAPI呼び出しも含まれていた。
• 最後の切断は21時50分14秒で、セッション全体は約9時間に及んだ。

Sysdigは、ツール一式が完成してからは、再接続のたびに同じ連鎖が数秒で完了していたと説明している。攻撃者がツールを組み立てて試行錯誤していたのは、最初の対話コマンドと最初のAWS API呼び出しの間の約4時間だった。

悪用された脆弱性「CVE-2026-39987」とは

CVE-2026-39987は、marimoのターミナル用WebSocketエンドポイント（/terminal/ws）が認証検証を行わずに接続を受け付けてしまう脆弱性だ。

GitHubのセキュリティアドバイザリ（GHSA-2679-6mx9-h9xc）によれば、同じアプリケーション内の別のWebSocketエンドポイント（/ws）はvalidate_auth()を呼び出して認証しているのに対し、/terminal/wsは認証確認を行わない。そのため、認証情報を持たないクライアントでもWebSocket接続するだけで、marimoのプロセス権限で動く対話シェル（PTY）を取得できてしまう。脆弱性の分類はCWE-306（重要な機能に対する認証の欠如）で、深刻度はCriticalとされている。

• 影響を受けるバージョン: marimo 0.23.0 未満
• 修正版: 0.23.0（2026年4月9日公開。修正はプルリクエスト#9098で行われた）
• アドバイザリ公開: 2026年4月8日
• 米CISAの「既知の悪用された脆弱性（KEV）」カタログへの追加: 2026年4月23日（連邦機関の対応期限は2026年5月7日）

Sysdigは別のブログで、この脆弱性が公開から10時間未満で悪用され始めたことも報告している（https://www.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours）。

AIを使わない攻撃者が「機械速度」に到達した

Sysdigによれば、この脆弱性を悪用する攻撃者はこれまで、大規模言語モデル（LLM）を使った攻撃者の痕跡が目立っていた。AWSのリクエスト署名コードを記憶から1行ずつ入力するといった挙動が確認されていたという。

今回の攻撃者はそれとは対照的だった。Sysdigは次の点を挙げている。

• 攻撃者はboto3（AWS用のPythonライブラリ）とparamiko（SSH用のライブラリ）を使ったツールを自分で書き、複数のセッションにわたってデバッグした。完成したスクリプトはbase64でエンコードし、echo '<base64>' | base64 -d > /tmp/<名前>.pyの形で**/tmp/に配置**した。以降は1つのコマンドで連鎖を実行できた。
• Sysdigは、LLMで動くエージェントを人間と区別するために仕掛けたプロンプトインジェクションのおとりを用意していた。以前に観測したLLM駆動の攻撃者はこのおとりに反応して目印を出力したが、今回の攻撃者はファイルを2回確認しただけで反応しなかった。
• 攻撃者は、EC2のインスタンス列挙が拒否された場面で、インスタンスIDが未設定のままプレースホルダー値でAPIを呼び出して失敗している。Sysdigはこれを人手特有のコーディングミスだとしている。

Sysdigは結論として、AIは攻撃の敷居を下げ、機械速度に到達しやすくしたが、機械速度そのものはAI以前から存在したと述べている。そして、防衛側はAIを使う攻撃者と熟練した人手の攻撃者の双方に備える必要があるとしている。

攻撃の連鎖としてSysdigが観測した内容

Sysdigが公表した内容によれば、攻撃者は次の流れで動いていた。

1. クラウド認証情報の窃取。攻撃者は、侵害したmarimoインスタンス上の環境変数と設定ファイルから1つ目のAWS認証情報を、アプリケーションのデータストア（Redis）から2つ目の認証情報を取得した。2つは別々のIAMユーザーに紐づいていた。最初の認証情報は、Sysdigが確認できた最初の端末操作より28時間以上前にAWSのAPIで検証されていた。
2. /terminal/wsへの接続。攻撃者は送信元のIPアドレス172.236.12[.]17から/terminal/wsへ接続し、認証なしでシェルを取得した。
3. ツールの配置。base64でエンコードしたスクリプトを/tmp/chain.pyや/tmp/full_chain.pyとして保存し、実行した。
4. 秘密情報の取得。secretsmanager:GetSecretValueを呼び出してSSH秘密鍵を取得し、/tmp/bastion_key（権限0600）に書き出した。
5. 踏み台ホストへのSSH認証。取得した鍵を使い、インターネットから到達可能な踏み台ホストへrootとして認証した。
6. 待ち受けの設置。攻撃者が所有するVPS（45.79.187[.]72）に対して、nc -lvp 4444でリバースシェルの待ち受けを設定した。
7. 別経路の試行。攻撃者はこれとは別に、Amazon EC2 Instance Connect（SendSSHPublicKey）で公開鍵を直接登録する経路も試した。ただしDescribeInstancesなどの列挙が権限不足で拒否され、インスタンスIDが未設定のままプレースホルダー値でAPIを呼び出したため失敗した。

Sysdigによれば、**シェルの送信元と待ち受け先はいずれも同じ Autonomous System（AS63949、Akamai Connected Cloud／Linode）**に属していた。Sysdigはこれを、同じ攻撃者を特定するための手がかりになるとしている。

Sysdigが示した検知のポイント

Sysdigは、攻撃者の種類（人手かAIか）に依存した検知は通用しないとしている。手入力のコマンド列とLLMが生成したコマンド列では見た目がまったく違う一方で、行き着く先は同じ（Secrets Managerからの秘密情報取得、SSH鍵の受け渡し、踏み台への外向き通信）だからだ。そのうえで、次の検知の観点を示している。

• 連鎖の形で見る。ノートブックのコンテナ内で/proc/self/environや.envを読むプロセスがあり、同じプロセスがsecretsmanager.<リージョン>.amazonaws.comへ外向きHTTPS通信を行い、同じ1分以内にコンテナから非RFC1918の宛先へ標準外ポートでTCP接続する、といった一連の流れを検知の単位とする。
• CloudTrailの地域フォールバック。履歴のないプリンシパルがsecretsmanager:GetSecretValueを呼び出してAccessDeniedExceptionで失敗し、直後に複数リージョンへ再試行する挙動は、信頼度の高い証拠になる。
• Sysdigは自社製品（Sysdig Secure）のコンテナドリフト検知と外向き通信のランタイムポリシー、およびAWS GuardDutyのUnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSが、この攻撃のホスト側とクラウド側をそれぞれ対象範囲に含むとしている。

Sysdigが推奨する対応

Sysdigは、この攻撃に対する対応として次を挙げている。

• marimoを0.23.0以降へ更新する（未更新の場合）。Sysdigは、この脆弱性が数か月にわたりCISAのKEVに掲載されており、連邦機関の対応期限が2026年5月7日とされていた点にも言及している。
• /terminal/wsをリバースプロキシ側で認証付きに制限するか、ターミナル機能を無効化する。Sysdigは「ノートブック基盤をインターネットに公開すべきではない」としている。
• ノートブックホスト上のクラウド認証情報の置き場所を洗い出す。Sysdigは、プロセスの環境変数（/proc/<pid>/environ）、systemdのEnvironmentFile、/.aws/credentialsと/.aws/config、アプリケーションの.env、実行時に参照されるシークレットストアを確認するよう求めている。今回の2つの鍵は別々のIAMユーザーに紐づいていたため、片方を消しても経路はふさがらないという。
• Secrets Managerへのアクセス範囲を絞る。ノートブックホストに置かれたIAMユーザーに、踏み台用のSSH鍵を読む権限を与えない。
• ノートブックコンテナからの外向き通信を制限する。Sysdigは、リバースシェルでよく使われるポート（4444、1337、1234、8080、9001、31337など）がノートブックの外向き通信に現れないようにすべきだとしている。
• 露出した可能性のある認証情報をローテーションする。Sysdigは、2026年4月8日以降に/terminal/wsへ到達できる状態があった場合、.envやアプリケーションのデータ層、環境変数の内容が露出したと想定するよう求めている。
• /tmp/に残るファイルを探索する。攻撃者が残したchain.pyやbastion_keyといったファイルは再利用できる状態で残るとしている。

出典

• Sysdig Threat Research Team「Machine speed, hold the AI: Hand-rolled marimo CVE-2026-39987 exploit」（2026年9月11日）: https://www.sysdig.com/blog/machine-speed-hold-the-ai-hand-rolled-marimo-cve-2026-39987-exploit
• Sysdig Threat Research Team「marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours」: https://www.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours
• GitHub Security Advisory「GHSA-2679-6mx9-h9xc」（CVE-2026-39987）: https://github.com/marimo-team/marimo/security/advisories/GHSA-2679-6mx9-h9xc
• 米CISA「Known Exploited Vulnerabilities Catalog」（CVE-2026-39987）: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-39987