同一週內，都因為 AI Agent 金鑰失守
2026 年 10 月 17 日，開源 AI 程式開發代理 OpenCode 的開發商 Anomaly Innovations 通知用戶，Console 系統遭未授權存取，約 1.4% 的 Console 用戶儲存的 OpenAI、Anthropic 與 Google API 金鑰可能外洩。同一天，台灣雲端部署平台 Zeabur 創辦人發信宣布，平台將於 12 月 31 日前全面停止服務，起因是不到七週內連續兩起資安事件，外洩的同樣是專案環境變數中的第三方 API 金鑰與資料庫密碼。
兩起事件的攻擊者目標一致。被偷的不是信用卡號或個資，而是能直接呼叫大型語言模型的 API 金鑰。這類金鑰一旦落入他人手中，受害者會在數小時內看到帳單暴增，而攻擊者得到的是不用付錢的模型算力。CyberQ 觀察這兩案的經過、對照其中的共同失誤，並依據實務經驗，提出金鑰管理的具體建議。
事件一 OpenCode 從一套退場中的舊 Console 被掏走金鑰
OpenCode 是以終端機為介面的開源 AI 程式開發代理，開發商 Anomaly Innovations 前身為 SST 團隊，工具本身免費，用戶自備 OpenAI、Anthropic、Google 等供應商的 API 金鑰接入模型。OpenCode Console 則是官方託管的工作區服務，可以把供應商金鑰存在雲端，這次出事的正是這個部分。
依 Startup Fortune 的報導，Anomaly Innovations 於 UTC 10 月 17 日 22:51 前後開始寄出主旨為「Action Required: Potential provider key breach」的通知信，說明入侵來自一套正在關閉中的 legacy Console 系統，儲存在用戶工作區內的第三方供應商金鑰可能已外洩。公司能辨識的最早曝險時間點約在 UTC 10 月 17 日 00:30，距離第一封通知信將近 22 小時。10 月 18 日 UTC 凌晨 1 時前公司再補發第二封信，列出受影響的金鑰種類。
Techmeme 與 Digg 轉述公司通知，受影響者約占 Console 用戶的 1.4%，公司將事件定性為「大規模蒸餾攻擊」（large scale distillation attack）。所謂蒸餾攻擊，是指攻擊者拿偷來的金鑰大量呼叫模型、蒐集輸出，用來訓練自己的模型。這項定性與 1.4% 的數字來自公司寄給用戶的信件，公司尚未公開信件全文，兩項資料待查。
公司在信中表示，無法確認外洩金鑰是否已遭惡意使用，調查至今沒有發現其他資料外洩。這個說法與用戶回報有落差。Startup Fortune 引述追蹤事件的日本開發者 zephel01 整理的時間軸，至少一名用戶在 10 月 17 日晚間就看到帳號出現未授權的 Claude API 用量，另一名用戶收到信時已被盜刷約 100 美元。Digg 彙整的 X 貼文中，有用戶稱只在 OpenCode 使用的 OpenAI 與 Anthropic 金鑰一夜之間被刷了 400 美元以上，另一名回覆稱損失 1,700 美元。這些金額均為用戶自述，待查。
供應商端的反應較公司本身更快。依 Pasquale Pillitteri 與 Digg 轉述，Anthropic 在 X 上表示已與 OpenCode 合作，撤銷判定涉入事件的 Claude API 金鑰，並建議曾把金鑰存在 OpenCode 的用戶重新建立。ThreatCluster 的彙整則引用 Google 員工 Evan Otero 在 X 的貼文，表示 Google 已知悉涉及 Gemini API 的 OpenCode 事件。兩則貼文原文待查。
Startup Fortune 另指出一個揭露方式的問題。截至報導時，OpenCode 的狀態頁、更新日誌與官方網站都沒有刊出公告，唯一的揭露管道是寄給已知受影響帳號的電子郵件，Hacker News 上標題為「OpenCode Hacked: User credentials leaked」的討論串對此提出質疑。資安研究員 Matt Johansen 與開發者 NetworkChuck 在 X 上轉發確認消息，事件才在社群擴散。
OpenCode 官方文件本來就寫明，這個代理不做沙箱隔離，權限提示屬於使用體驗設計而非安全邊界，建議需要隔離的用戶使用 Docker 或虛擬機。問題在於，這次外洩的地點不在用戶端，而在用戶看不到的供應商舊系統。用戶再怎麼限制本機權限，也擋不住金鑰從後端被讀走。
事件二 Zeabur 七週內兩次失守，第二次後三天宣布停業
Zeabur 成立於 2023 年，是台灣團隊創立、登記於美國的雲端部署平台，主打讓開發者把網站、資料庫與 n8n 等自動化工具一鍵上雲。依 蕃新聞 報導，創辦人林沅霖於 10 月 17 日發信通知用戶，即日起停止新的專用伺服器與網域購買，專用伺服器 12 月 1 日起停止續費並依到期日陸續關閉，共享叢集同日暫停運行，12 月 31 日全面停止服務。帳戶餘額退款與資安事件損失賠償須分別向 Zeabur Support 申請。
第一次事件 2026 年 8 月 27 日
Zeabur 於 9 月 7 日發布的 官方調查報告 把攻擊路徑交代得相當完整。攻擊者先利用用戶部署在共享叢集上的 NextChat v2.16.1 的 CVE-2026-7644 漏洞取得容器內程式執行權，再透過共享叢集內網讀取路由快取，快取裡存有不支援權限範圍、也沒有有效期限的 Zeabur Legacy API Key。攻擊者篩出一組團隊管理員金鑰，用它讀取內部管理服務的環境變數，取得長期保存的 AWS root 金鑰，接著取得東京共享叢集的控制權，最後借用一項維運定時任務持有的私有網路連線與資料庫憑證，進入正式環境資料庫大量讀取專案環境變數。
報告列出的時間軸顯示，UTC 8 月 27 日 02:34 出現最早的異常請求，07:54 出現資料庫入侵紀錄，11:52 起環境變數遭大量讀取，而團隊是在 8 月 28 日 02:34 收到用戶回報 API 金鑰遭盜用後才確認事件，當時的監控與告警沒有辨識出未授權存取。被讀走的內容包含 AI 服務與其他第三方 API 金鑰、雲端存取憑證、資料庫連線資訊與密碼、應用程式簽章金鑰。依 恆遠數位科技 整理，Anthropic、OpenAI、OpenRouter 的金鑰已被觀察到遭盜用。
Zeabur 在報告中承認內部憑證保存與權限劃分、共享叢集網路隔離、異常存取監控與告警三方面不足，並寫下一句關鍵的檢討，共享叢集與 Legacy API Key 雖已進入退場階段，仍應確保它們在停止運作前具備足夠的隔離與存取限制。事後的改善包括全面停用 Legacy API Key、把環境變數改存放於用戶自己的專用伺服器、AI Hub 於 9 月 22 日停止服務。但環境變數新存放方式只適用於專用伺服器，共享叢集上的服務不會自動切換。
第二次事件 2026 年 10 月 14 日
依 Zeabur 狀態頁，UTC 10 月 15 日 16:08 首次公告在共享叢集環境偵測到異常存取，確認仍在已淘汰共享叢集上運行的用戶 PostgreSQL 與 MySQL 服務遭未授權存取，當時表示沒有證據顯示專用伺服器受影響。同日 20:48 的更新推翻前述說法，事件範圍比最初回報更廣，部分架在 Google Cloud 上的專用伺服器也遭未授權存取，攻擊者握有平台資料庫的讀取權，外洩資料包含服務環境變數、帳號資訊、API Token 與 zSend API 金鑰。
官方處置包括撤銷已辨識的外洩憑證、輪替登入簽章金鑰（所有用戶需重新登入）、暫時限制 Google Cloud 專用伺服器的公開 SSH 連線。狀態頁要求用戶輪替環境變數中的所有秘密、重新產生 Zeabur API Token，Google Cloud 專用伺服器用戶另需更改 root 密碼並刪除不認得的 SSH 金鑰，特別點名標示為 zeabur-pentest 的那一把。依恆遠數位科技引述的 10 月 15 日用戶通知信，攻擊者這次取得的是共享叢集的平台管理憑證，直接進入用戶容器執行指令，主要目標是 n8n、PostgreSQL、MySQL、Redis 與 AI 相關服務。管理憑證如何外洩，官方尚未公布，待查。
停業的三個理由
依恆遠數位科技對停運公告信的整理，林沅霖提出三個理由。其一，AI 快速降低應用部署本身的門檻，平台成長遇到瓶頸。其二，系統從三年半前的快速開發專案起步，一路調整架構，複雜度與維護成本持續上升。其三，下半年兩起資安事件讓團隊看見安全與維運的不足。蕃新聞另報導，台北市法務局主任消保官林傳健表示，業者結束營業無法履約，依民法負有回復原狀義務，待退金額原則應以消費者原支付貨幣返還，由於 Zeabur 登記於美國且未在台灣設立分公司，屬境外消費爭議，消費者可循 eConsumer.gov 或向發卡銀行申請爭議款。
兩案對照 退場中的舊系統，集中存放的金鑰
CyberQ 觀察，兩家公司規模、產品與國家都不同，失守的方式卻高度相似。下表把已公開的事實並列。
| 項目 | OpenCode（Anomaly Innovations） | Zeabur |
|---|---|---|
| 產品性質 | 開源 AI 程式開發代理，Console 為官方託管工作區 | 雲端部署平台（PaaS） |
| 入侵點 | 正在關閉中的 legacy Console 系統 | 8 月為退場中的共享叢集與 Legacy API Key，10 月為共享叢集平台管理憑證 |
| 被偷的資產 | 用戶存在工作區的 OpenAI、Anthropic、Google 金鑰 | 專案環境變數中的 AI 金鑰、雲端憑證、資料庫密碼，10 月另含資料庫內容與 API Token |
| 攻擊者用途 | 公司定性為大規模蒸餾攻擊，用戶回報金鑰遭盜刷 | 8 月已觀察到 Anthropic、OpenAI、OpenRouter 金鑰遭盜用 |
| 影響規模 | 約 1.4% 的 Console 用戶（待查） | 官方未公布用戶數，10 月範圍擴及部分 Google Cloud 專用伺服器 |
| 偵測方式 | 公司最早曝險時間與通知相隔約 22 小時，用戶先於公司發現盜刷 | 8 月由用戶回報金鑰遭盜用後才確認，監控未辨識 |
| 揭露管道 | 僅電子郵件通知受影響帳號，狀態頁與官網無公告 | 狀態頁、電子郵件、完整調查報告，10 月狀態頁一日內更正範圍 |
| 後續 | 要求用戶自行撤銷並重建金鑰，供應商協助撤銷 | 第二次事件後三天宣布 12 月 31 日前停業 |
從表中可以看出三個共同點。
第一，入口都是已經標記為淘汰、但還在運作的舊系統。OpenCode 是 legacy Console，Zeabur 是 2 月就宣布退場的共享叢集與 Legacy API Key。Zeabur 的調查報告自己寫得很清楚，退場中的系統在真正關閉前仍需要足夠的隔離與存取限制。這是所有軟體公司都會遇到的拉扯，資源投向新產品，舊架構只求不倒，而攻擊者專挑沒人看守的門。
第二，被偷的都是可以立刻變現的 AI 金鑰。信用卡號要洗錢，個資要找買家，LLM 的 API 金鑰偷到手當下就能用。攻擊者可以拿來跑蒸餾、賣算力、或是單純刷到額度用完。OpenCode 用戶回報的 400 美元到 1,700 美元損失，Zeabur 8 月事件後開設的 AI 金鑰盜刷補償流程，都指向同一種動機。
第三，兩家公司都比用戶晚發現。OpenCode 的用戶在收到通知前就看到帳單異常，Zeabur 8 月是靠用戶回報才確認入侵。金鑰外洩的第一個徵兆往往出現在供應商帳單上，而不是在平台自己的日誌裡。
兩案也有明顯差異。Zeabur 公開了完整的攻擊路徑與時間軸，10 月的狀態頁在數小時內更正影響範圍，三天後給出停業時程與退款安排。OpenCode 截至報導時只以電子郵件通知已知受影響的帳號，公開管道沒有任何說明。資安事件的揭露品質，與公司最後能不能留住用戶，兩者的關聯值得後續觀察。
使用者與企業該做什麼 把 AI 金鑰當成現金管理
CyberQ 觀察，兩起事件的受害者有一個共通處境，金鑰交給了平台，平台的後端出事，自己完全沒有能力阻止。能做的只有把損失上限壓低，以及縮短發現的時間。
現在就該做的事
- 曾把供應商金鑰存在 OpenCode Console 或 Zeabur 環境變數的人，直接到 OpenAI、Anthropic、Google 的後台撤銷舊金鑰並重建，不要點通知信裡的連結。只建新的不撤舊的，舊金鑰照樣能用。
- 檢查 10 月 14 日（Zeabur）與 10 月 17 日（OpenCode）之後的用量與帳單，截圖留存，申請補償時會用到。
- Zeabur 用戶的資料庫密碼要先在資料庫內執行改密碼指令，再更新平台上的變數並重啟服務。只改平台變數，資料庫實際密碼沒有變。
- 在每一家 AI 供應商的後台設定每月花費上限與用量告警。這是唯一不依賴平台、由用戶自己掌控的止損手段。
長期的金鑰管理原則
- 一把金鑰一個用途。給 OpenCode 的金鑰、給 CI 的金鑰、給正式服務的金鑰分開建立，並以供應商後台的專案或工作區功能隔離額度。某一把外洩時，撤銷它不會影響其他系統。
- 能用短效憑證就不用長效金鑰。OpenCode 這類本機代理可以透過供應商的 OAuth 登入取得有期限的權杖，比把長效 API 金鑰存在第三方雲端安全。
- 秘密集中在自己掌控的秘密管理服務，平台只在執行時讀取。Zeabur 8 月之後推出的環境變數存放在用戶伺服器的做法，方向正是如此，但只適用於專用伺服器，留在共享叢集的服務沒有受惠。
- 盤點組織內所有存放 AI 金鑰的地方。多數團隊的金鑰散落在開發者的本機設定檔、n8n 的 credentials、CI 的 secrets、各家 PaaS 的環境變數裡，沒有人有完整清單。沒有清單就無法在事件發生時判斷哪些該換。
- 選用平台型服務時，先寫好出口計畫。程式碼在自己的 Git 倉庫、資料每日備份到平台以外、網域在自己的註冊商、部署設定寫成檔案跟著程式碼走。Zeabur 給用戶的搬遷時間不到十一週，資料刪除日期與匯出期限至今未公布。
給平台業者的提醒
Zeabur 的調查報告與 OpenCode 的通知信都指向同一個盲點，退場中的系統沒有人負責。宣布淘汰不等於風險消失，在真正下線之前，舊系統仍需要與新系統相同等級的隔離、監控與憑證輪替。另一個常被忽略的是偵測能力，兩家公司都是靠用戶的帳單異常才知道出事。若平台持有用戶的供應商金鑰，就應該與供應商建立通報管道，或至少在平台端監控金鑰的呼叫模式，而不是等用戶來報案。
延伸閱讀 :
OpenCode breach exposes stored OpenAI and Anthropic keys, prompts urgent key rotation
OpenCode breach may have exposed stored OpenAI, Anthropic and Google keys
OpenCode hacked, API keys for OpenAI, Anthropic and Google at risk
OpenCode Security Breach Exposes User API Keys
Unauthorized Access to Zeabur Infrastructure and User Data
