資安公司 Sysdig 在 2026 年 7 月初公開一份調查：一個代號 JADEPUFFER 的攻擊，從頭到尾由一個大型語言模型代理自己執行，完成了一整套勒索流程。它自動找漏洞進入主機、蒐集金鑰、掃內網、攻破資料庫、加密設定再刪表，最後留下勒索訊息。Sysdig 稱這是第一個有紀錄、端到端由 LLM 代理驅動的勒索案例。
但真正該讓台灣的 IT 和開發者坐直身子的，不是「AI 學會攻擊了」這種恐慌標題。這週該關掉的，不是 AI 代理，而是那台你可能已經忘記、卻還開在公開網路、還連得到正式資料庫的 demo 主機。因為 JADEPUFFER 賴以放大的每一個條件——對外暴露的服務、主機上的長期金鑰、能直通生產資料庫的內網路由——都是我們自己沒收好的老問題，只是這次被機器速度一次收割。
先把話說清楚，也把不確定的地方說清楚。
這次確認了什麼，還沒確認什麼
可以放心寫下的有兩層。第一，入口漏洞是真的、而且是舊帳。它利用 Langflow 的 CVE-2025-3248：1.3.0 以前的版本，有一個對外端點會直接執行使用者送進來的程式碼，未經驗證的攻擊者就能遠端執行任意指令，CVSS 評為 9.8。這個洞不新——早在 2025 年 4 月就被收錄、5 月就進了美國 CISA 的「已知遭利用漏洞」清單，先前還被殭屍網路 Flodrix 打過。換句話說，把舊版 Langflow 開在公開網路，本來就是遠端執行風險，JADEPUFFER 只是讓後面的自動化攻擊鏈第一次被完整看見。
第二，Sysdig 觀察到的攻擊鏈很具體：進入主機後蒐集雲端金鑰（特別針對阿里、騰訊、華為等中國雲服務）、加密貨幣錢包和資料庫帳密；傾印 Postgres 資料庫；用預設憑證翻 MinIO 儲存；再橫移到跑 Nacos 和 MySQL 的生產伺服器，偽造權杖、植入後門管理員帳號；最後 AES 加密 1,342 筆 Nacos 設定、刪掉設定表、對多個資料庫下刪除指令，留下勒索訊息和比特幣位址。判斷它由代理驅動的依據，包含攻擊碼裡大量自然語言註解，以及一段招牌細節：Nacos 登入失敗後，它在 31 秒內自己診斷出問題、改寫指令重試。
但有三件事 Sysdig 自己明講無法確認，這也是這則新聞最該保留分寸的地方。它看不到 JADEPUFFER 用的是哪個模型、哪家供應商；它沒看到那組資料庫 root 憑證從哪來，來源不明；勒索訊息裡「資料已備份外傳」是攻擊者的自述，不等於外傳已被獨立驗證。連比特幣位址都有兩種解讀，因為 Sysdig 看不到它的系統提示。所以比較安全的說法是：有一條由代理自動執行、會自我修正的勒索鏈被觀察到了——但「AI 已經能自己發動攻擊」這句話，還有一大塊留白。
一個舊漏洞，怎麼被放大成整條勒索鏈
Langflow 這類工具，是拿來快速把模型、資料源、API 和自動化節點串起來的。方便正是風險的來源。團隊測試時為了快，把 OpenAI、雲端、資料庫的金鑰塞進環境變數；為了給同事試用，把服務開上公開網路；為了讓流程跑得動，主機還能連到內網。這三個習慣疊在一起，一個 RCE 漏洞就從「單台 demo 被入侵」變成「整個資料庫被當人質」。
真正變了的是速度。傳統防禦常假設攻擊者需要時間觀察、手動整理、改腳本，那段時間就是偵測窗口。JADEPUFFER 把它壓到幾十秒：登入失敗、立刻改招、換個解析方式繼續。人還在看錯誤訊息，代理已經走下一步了。這代表告警不能只等到明顯外傳或勒索訊息出現，得往前挪到那些早期行為——主機突然大量讀設定檔、用應用程式身分連資料庫管理埠、在短時間內連續修正失敗指令。
資安署三月就把答案寫好了
這裡是台灣讀者最該知道、多數英文報導卻不會提的一點：你不用等 JADEPUFFER，台灣主管機關三個月前就把防線列好了。 數位發展部資安署在 2026 年 3 月 25 日發過一則警示，針對 AI 代理工具 OpenClaw 的漏洞，提醒導入時要落實五項防護。把那五項對照 JADEPUFFER 打穿的環節，幾乎逐條命中：
| 資安署三月的五項防護 | JADEPUFFER 打穿的環節 |
|---|---|
| 環境隔離（獨立機器／虛擬機／容器） | 主機沒隔離，一被入侵就摸到內網 |
| 外部帳號權限最小化（專屬帳號） | 拿到能連生產資料庫的高權限憑證 |
| 高風險操作強制人工審核 | 加密、刪表全自動，沒有人攔得下 |
| 安裝擴充前完整安全掃描 | 對外服務本身就是未修補的入口 |
| 把安全守則寫進代理的長期記憶 | 代理沒有被約束的邊界 |
所以這則新聞對台灣團隊的意義，不是「又一個嚇人的 AI 威脅」，而是「不照做的代價，被演了一遍」。你可以直接把資安署這五項當成內部說服老闆的骨架，比自己重寫一份清單更有在地權威。
72 小時，先做這幾件事
先收回入口。 檢查有沒有 1.3.0 以前的 Langflow、未經驗證的 demo、或測試用的 AI 編排伺服器暴露在公開網路。能關就先關；必須留的，先放到 VPN 或內網後面，再升級修補。
把金鑰當成已經外洩。 只要主機曾經對外，環境變數、設定檔、儲存桶裡的雲端金鑰、資料庫密碼都要輪替，並查過去 7 到 30 天的使用紀錄有沒有異常來源。
切斷 demo 主機到生產資料的捷徑。 AI 代理的測試機不該拿 root 資料庫帳號，也不該掃得到內網的 Nacos、MySQL、MinIO。真的要讀資料，先給唯讀、短期、範圍受限的帳號，寫入留給人工確認。
把復原演練做完。 JADEPUFFER 的殺傷力在加密加刪除。備份如果沒測過還原，就不算防線。挑一個非生產資料庫實際還原一次，確認備份完整、時間符合業務承受範圍。
企業要把這件事系統化，可以接到 AI-SPM（AI 資安態勢管理） 的代理權限盤點；對代理的系統邊界與行為紀錄還沒有共通語言的團隊，先看 AI Agent 安全的系統性問題；正在把 coding agent 接進程式庫的，則對照 企業 AI Coding Agent 評估指南 檢查寫入權限。
低風險團隊的輕量路線
不是每個人都需要立刻買新平台。如果你只是個人研究或小團隊 demo，最小可行防線只有三句話：demo 主機上不放長期金鑰、不連正式資料庫、測完就關。這三件事零成本、當天就能做，剛好擋掉 JADEPUFFER 賴以放大的三個條件。真正要花錢的代理治理，是有內網代理的企業才需要往下接的第二層。
也別以為台灣是旁觀者。AI 加持的勒索攻擊已經打進台灣——CrazyHunter 自 2025 年 3 月起專打台灣，從醫院擴大到上市櫃公司，運用 AI 與深偽強化攻擊。截至 2026 年 7 月，台灣主管機關雖然還沒有針對 JADEPUFFER 的專門通報，但資安署三月那則 AI 代理警示，已經涵蓋了同一類風險。
常見問題
JADEPUFFER 是不是「AI 自己」發動的攻擊？
不能這樣講死。Sysdig 觀察到的是一條由代理自動執行、會自我修正的勒索鏈，但它明說看不到背後用哪個模型、操作者是誰，勒索訊息裡的外傳主張也未經獨立驗證。比較安全的說法是：機器把攻擊速度壓到幾十秒，但「AI 完全自主發動」仍有一大塊留白。
我沒有用 Langflow，是不是就沒事？
不是。Langflow 只是這次的入口，真正的風險是「把任何 AI 編排或代理工具開在公開網路、又放了長期金鑰、還連得到正式資料庫」。n8n、AutoGen、自建代理 demo 都適用同一套檢查：先關對外入口、輪替金鑰、切斷到生產資料的通路。
只把 Langflow 升級到 1.3.0 以上就夠了嗎？
不夠。升級能堵住已知入口，但只要主機曾經對外暴露，上面的金鑰、資料庫密碼、內網權杖都要當成可能外洩，一併輪替並查使用紀錄。有可疑紀錄時，先確認備份能還原，再談後續。