實際事件 發布於 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
7 項對應的 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）和內容一起匯出、送到環境外。

適用的 7 項 AIDEFEND 防禦手法

AID-H-004.001
User & Privileged Access Management
極高
marimo 的 terminal WebSocket 與 notebook 是人類操作員使用的介面。使用者在建立 terminal 或執行 notebook 程式碼前，必須通過身分驗證、MFA、最小角色權限與 privileged session 控制，避免匿名瀏覽器請求直接變成主機 shell。下游模型服務、data store 或 MLOps 呼叫的 workload authentication，則是 AID-H-004.002 的另一個邊界。
AID-I-001.004
Sandbox Network Egress Restrictions
極高
這條攻擊鏈，依賴受害執行環境可以對外連到雲端 API、Cloudflare Workers、SSH 和內部資料庫路徑。notebook 和程式碼執行沙箱如果預設禁止對外連線，只開必要目的地，就能大幅降低 RCE（遠端程式碼執行）後連回攻擊者控制的服務、拿偷來的憑證繼續嘗試存取，以及橫向移動的機會。
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
極高
這起事件的 marimo notebook 能從公網直接連到，因此應從不可信網路位置、不帶企業憑證地探測組織擁有的 notebook 與 agent 路徑。核對負責人、公開用途與驗證狀態後，對未登記、找不到負責人或意外公開的終端機送出精確 finding；實際修正由其他控制負責。
AID-I-002.001
Internal AI Network Segmentation
高
這個入侵案例之所以嚴重，是因為被攻陷的資料科學執行環境能一路靠近 AWS Secrets Manager、bastion 和內部 PostgreSQL 資料庫。網路分段和微分段應該阻止對外的 AI notebook 直接連到高價值的內部資料庫,或連上管理用的跳板主機。
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
高
把每個已部署的 marimo notebook 版本與 terminal WebSocket 漏洞公告逐一核對，重建修正版並分階段推出，最後驗證已沒有任何弱點 runtime 仍對 Internet 開放或持續提供服務。這項控制直接負責軟體修補與 fleet completion。
AID-D-005.003
Proactive AI Threat Hunting
高
以明確假設主動獵捕，跨 notebook、雲端、端點、身分與資料庫遙測，串起 terminal WebSocket 存取、憑證檔列舉、STS 和 Secrets Manager 呼叫、Cloudflare Workers 多 IP 對外連線、短時間 SSH 工作階段，以及 PostgreSQL 大量匯出。重點是即使 agent 每次組出的指令不同，仍能找出相同攻擊目的，而不是只等單一預先定義的特徵命中。
AID-E-001.001
Root & Long-Lived Credential Object Eviction
中
攻擊者能持續在環境中橫向移動，是因為初始入侵後拿到了 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 和內部資料庫的捷徑，進而造成更大的傷害。