事件經過
埋下隱患： 2025 年 12 月，Cline 的維護團隊在公開的程式碼庫中加入了一個 AI 助手，用來自動閱讀並回覆大眾提交的錯誤回報。設定上，任何帳號提交回報都會觸發它，且它具備在處理任務的電腦上直接執行命令的能力。
發現漏洞： 新年剛過，有安全研究人員發現了這個可以欺騙 AI 的漏洞，並正式寄信向開發團隊通報。幾週後，系統的自動打包作業與共用儲存區開始出現不尋常的錯誤，目前無法確認這是其他研究人員在測試，還是真正的駭客攻擊。
緊急修補與疏漏： 維護團隊在 30 分鐘內迅速移除了 AI 助手，並將共用儲存區切開。隔天，團隊對外表示已更換所有金鑰。然而再隔一天，有人回報部分舊金鑰竟然還能使用，迫使團隊又重新更換了一次。
爆發災情： 事件公開八天後，Cline 在一個名為 npm（供開發者下載與更新程式套件的公開平台）上，出現了一個未經授權的 2.3.0 版本。這個版本是有人利用「未被徹底作廢的舊金鑰」所發布的，至今不知發布者是誰。這個惡意版本與正常的版本幾乎一模一樣，只多加了一行程式碼：它會在所有更新此版本的電腦上，偷偷安裝另一個擁有執行命令、讀取檔案與瀏覽網頁權限的 AI 助理。
後續處置： 這個惡意版本在平台上存活了約八小時。隨後，維護團隊緊急發布了安全的 2.4.0 版，將惡意版本標記為淘汰，並真正作廢了那把惹禍的金鑰。雖然這個工具有超過 500 萬名使用者，但目前無從得知在那八小時內有多少人受害。萬幸的是，維護團隊檢查了另一個發布管道（軟體編輯器的擴充套件市集），確認那裡並沒有遭到惡意版本入侵。事後，團隊修改了發布流程，不再使用長期有效的金鑰來降低風險。
主要來源——S1：https://snyk.io/blog/cline-supply-chain-attack-prompt-injection-github-actions存檔快照
損失成因
- 把惡意留言當成系統指令陌生人在回報單裡寫的文字，和工程師下的指令，在 AI 眼中沒有任何區別。加上這個 AI 具備執行命令的權限，導致回報單裡的一句惡意文字，直接變成了建置機器上的一道破壞性指令。技術名稱：間接提示注入（indirect prompt injection）
- 讓 AI 自己監管自己AI 「該做什麼、不該做什麼」的規則，只是一段寫給 AI 看的文字指示。當惡意文字成功誤導了 AI，這些安全檢查也就形同虛設，因為「負責檢查的」和「被誤導的」是同一個 AI。僅靠口頭規則來限制 AI，是無效的作法。技術名稱：自我裁決的指令（self-adjudicated instructions）
- 測試環境與正式環境混用任何人都能觸發的 AI 作業，與握有正式發布金鑰的作業，竟然共用同一個儲存區。這個儲存區容量滿了就會自動刪除舊檔案，導致一個作業的檔案可以輕易蓋掉另一個作業的檔案。攻擊者只要能碰到這個大眾共用的儲存區，就等於碰到了出貨產品的正式核心。技術名稱：生產與開發共用基礎設施（shared prod-dev infrastructure）
- 沒有確實查驗舊金鑰是否失效團隊雖然宣告「金鑰換了」，卻沒有逐一檢查舊金鑰是否真的失去效力。金鑰不會自己過期，必須由發放公司確認撤銷才算數。這次的災難就是因為團隊在清理時漏掉了一把舊金鑰，導致它仍具備發布正式軟體的權力。技術名稱：未經逐一驗證的憑證撤銷（unverified credential revocation）
預防方式
假設陌生人的文字都是潛在的系統命令
請工程團隊列出目前所有掛在公開專案上的 AI 助手。只要該助手同時滿足「會接收陌生人文字」且「能在機器上執行命令」兩個條件，請立刻暫停使用，除非你已經有十足把握能控制其風險。
限制要設在系統權限上，而不是只寫在 AI 的指示裡
給 AI 的文字指示只能算「建議」，不能當作防護網。真正的限制必須設定在 AI 使用的帳號和金鑰上。你可以問 AI 供應商一個問題：如果這個 AI 被騙了，它擁有的權限最壞能造成什麼後果？
徹底隔離正式發布的作業環境
負責發布正式產品的系統，絕對不能和其他工作共用帳號、金鑰或儲存區。必須確保正式發布系統不會讀取到陌生人能觸發的檔案；同時，測試環境所使用的帳號與金鑰，也必須與正式環境完全切開。
「金鑰已更換」必須眼見為憑
在安全事件發生後，請向團隊索取舊金鑰的完整清單，並要求看到「舊金鑰確實被拒絕存取」的測試證據。最好改用會自動過期的短期金鑰，這樣即使清理時漏掉一把，它也會時間一到自然失效，而不是像定時炸彈一樣永遠潛伏在系統中。