部落格 發布於 AIA: 2026年6月6日

marimo 被攻陷後：LLM agent 如何接手入侵後操作並轉進內部資料庫

Sysdig 觀察到一場 2026 年 5 月 10 日的入侵：攻擊者先利用 CVE-2026-39987 連上對外開放的 marimo notebook（marimo 是類似 Jupyter 的 Python notebook，可以在瀏覽器裡互動執行 Python 程式碼），接著讓 LLM agent 接手入侵後操作（post-exploitation），一路做憑證蒐集、AWS Secrets Manager 存取、透過 SSH 登入 bastion 跳板主機，再從那裡連到內部 PostgreSQL 資料庫，把資料庫結構和內容大量匯出並外傳。這篇的重點不只是修補 marimo。AI 與資料科學執行環境需要更早的驗證、權限範圍更小且效期更短的憑證、對外連線限制、內網分段，以及能辨識憑證蒐集、橫向移動和資料外傳的監控和警示。

Remote Code ExecutionCredential TheftRuntime IsolationCredential GovernanceAgentic AI
6 項對應的 AIDEFEND 防禦手法
來源: AI agent at the wheel: How an attacker used LLMs to move from a CVE to an internal database in 4 pivots 
作者: Michael Clark (Sysdig Threat Research Team)
原文發布: 2026年5月26日

威脅分析

  • 初始入口是一個 notebook shell。 攻擊者連到有漏洞、可從網際網路存取的 marimo instance 上的 /terminal/ws，透過 CVE-2026-39987 取得命令執行能力。
  • 取得命令執行能力後，攻擊者先找憑證。 工作階段讀取環境檔、.env 路徑、process 環境變數和 ~/.aws/credentials，再用取得的 AWS key 來呼叫 STS（Security Token Service，AWS 用來確認身分並簽發臨時憑證的服務）和 Secrets Manager。
  • 第二個轉進點把 secret 變成 SSH 通道。 攻擊者取出 SSH private key，透過 Cloudflare Workers 作為對外連線池，先 SSH 登入下游 bastion 跳板主機，再從那裡繼續靠近內部資料庫。
  • Sysdig 從指令內容判斷，這批指令，不像是人類在終端機裡手動操作，而是 agent 產生並執行的。 有些規劃註解被一起送出，shell 指令被分隔符號切成一段一段，輸出被刻意縮短，PostgreSQL 查詢也被包成一次性的 psql heredoc（一段直接嵌在 shell 指令裡、一次餵給 psql 執行的查詢內容）。後續指令還會接著使用前一步工具輸出的結果。
  • 最後結果是內部資料庫內容被大量匯出並外傳。 攻擊者登入 bastion 跳板主機後連上 PostgreSQL，先列出資料庫裡有哪些資料表，再從表名猜出哪些存著高價值的 AI 工作流程資料，並在不到兩分鐘內把這些資料表的結構（schema）和內容一起匯出、送到環境外。

適用的 6 項 AIDEFEND 防禦手法

AID-H-004.002
Service & API Authentication
極高
最早可以阻斷攻擊的地方，是 terminal WebSocket，以及任何能碰到 shell、secrets 或內部服務的 AI notebook 控制面。服務和 API 驗證必須在建立 terminal、執行 notebook、呼叫模型服務 API、存取資料庫或 MLOps 動作之前就完成，避免沒有通過驗證的請求，直接取得主機上的 shell 權限。
AID-I-001.004
Sandbox Network Egress Restrictions
極高
這條攻擊鏈，依賴受害執行環境可以對外連到雲端 API、Cloudflare Workers、SSH 和內部資料庫路徑。notebook 和程式碼執行沙箱如果預設禁止對外連線，只開必要目的地，就能大幅降低 RCE（遠端程式碼執行）後連回攻擊者控制的服務、拿偷來的憑證繼續嘗試存取，以及橫向移動的機會。
AID-I-002.001
Internal AI Network Segmentation
高
這個入侵案例之所以嚴重，是因為被攻陷的資料科學執行環境能一路靠近 AWS Secrets Manager、bastion 和內部 PostgreSQL 資料庫。網路分段和微分段應該阻止對外的 AI notebook 直接連到高價值的內部資料庫,或連上管理用的跳板主機。
AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
高
marimo 是否對外、terminal 是否開啟、憑證放在哪裡、版本有沒有修補，都是部署設定問題。安全基準應該擋下未經核准驗證的對外 notebook shell，要求 marimo 使用已修補版本，定義哪些 workload 可以持有雲端憑證，並要求任何破例都要說明由誰核准、誰負責，並設定到期時間，時間到就重新審查。
AID-D-005.002
Security Monitoring & Alerting for AI
高
Sysdig 的證據，本質上都是監控可以觀測到的活動：terminal WebSocket 存取、憑證檔列舉、STS 和 Secrets Manager 呼叫、Cloudflare Workers 多 IP 對外連線、短時間 SSH 工作階段，以及 PostgreSQL 資料大量匯出。看得懂 AI 行為的監控，應該針對這些攻擊意圖示警，而不是只等同一組固定指令重複出現（因為 agent 每次組出來的指令都不一樣，只偵測固定的指令特徵的話，會漏掉攻擊）。
AID-E-001.001
Foundational Credential Management
中
攻擊者能持續在環境中橫向移動，是因為初始入侵後拿到了 AWS key、SSH 材料和資料庫密碼。只要 marimo 執行環境曾經對外或疑似被攻陷，就要立即輪替雲端憑證、API key、資料庫密碼、SSH key，以及任何該 process 能碰到的長效服務憑證。

身為資安防禦者，我們應該這麼做

  • 把 marimo 升級到 0.23.0 或更新的版本。若暫時無法升級，先限制 /terminal/ws 存取、停用 terminal 功能，並把 notebook 服務限制成要先過嚴格的身分驗證、且只能走私有網路才連得到。
  • 盤點所有對外的 notebook、AI 沙箱、資料科學 UI，以及 MCP 或 agent 開發介面。記錄每個介面是否能執行 shell、讀取環境變數，或連到雲端 API。
  • 只要 marimo 主機曾經暴露在網際網路上，就作廢和重新換發該主機可能存取到的憑證，包括 AWS key、API key、資料庫密碼、SSH key、本機 secrets 和服務憑證。
  • 把 notebook 和程式碼執行 workload 放進預設禁止對外連線的沙箱。只加入經審核的目的位址，並避免雲端 API、bastion 和內部資料庫出現在預設路徑上。
  • 用網路分段把內部資料庫和 bastion 跟 AI 實驗主機隔開。除非透過一條經核准、有可稽核存取紀錄的路徑，否則對外 notebook 不應該發現正式資料庫、SSH 進入能連到它的主機，或對它下查詢。
  • 新增偵測：讀取憑證檔、secretsmanager:GetSecretValue 短時間爆量、每次請求換 IP 的對外連線池、一台主機突然對多台發出 SSH 連線（不尋常的一對多 SSH）、大量分隔符號的 shell 探測，以及 notebook 活動後接著出現資料庫內容大量匯出。

結論

Sysdig 的 marimo 案例值得被收錄進 AIDEFEND  in Action，原因不是 LLM 發明了全新的漏洞利用，而是它讓傳統 RCE 後面的入侵後操作變得更便宜、更快，也更能依環境調整。AIDEFEND  在這裡對應到的防線包括：服務驗證要夠早、沙箱對外連線要收斂、內網要分段、部署設定要守安全基準、監控要看得懂 AI 環境裡的可疑行為，以及憑證要能快速輪替。務實目標是讓 AI notebook 萬一被攻陷時，也只是一個損害可控的事件，而不是通往雲端 secrets 和內部資料庫的捷徑，進而造成更大的傷害。