OpenCode Console API 金鑰外洩事件：事件說明與應變措施

By shortie資訊科技

2026 年 10 月 17 日，AI 程式開發工具 OpenCode 證實發生安全事件：它的雲端工作區 OpenCode Console 中，一套正在退役的舊系統遭到未授權進入，使用者寄放在裡面的第三方 AI 供應商 API 金鑰可能因此外洩。已經有使用者回報，自己的帳單出現不是自己產生的費用。

這篇把公開資訊整理成一份通用說明：事件是什麼、哪些已經確定、哪些還不確定，以及個人和企業現在可以怎麼應變。

截稿時間：2026 年 10 月 19 日晚間（台北時間）。事件仍在進行中，之後若 OpenCode 或各供應商發布正式調查報告，請以正式報告為準。

三十秒看懂這次事件

  • 出事的是雲端工作區 OpenCode Console，不是裝在自己電腦上的 OpenCode 程式。只存在本機的金鑰不在這次通報的範圍內。
  • 可能外洩的是「別家公司的鑰匙」。使用者把 OpenAI、Anthropic、Google 等供應商的 API 金鑰寄放在 Console，由 Console 代為呼叫模型。寄放處的舊系統被人走進去，鑰匙就可能被複製。
  • OpenCode 說受影響的是 1.4% 的 Console 使用者，而且是其中有連結外部供應商的那一部分；受影響者已在 10 月 17 日收到通知信。
  • 最重要的應變：到各供應商自己的後台撤銷舊金鑰、換新金鑰、核對帳單。只在 OpenCode Console 裡刪除連線，不能讓已經被複製的金鑰失效。

先弄清楚：鑰匙存在哪裡

OpenCode 這個品牌底下有兩種產品，存放金鑰的地方不同：

產品金鑰存在哪裡這次是否在範圍內
OpenCode（本機程式）自己的電腦。舊版存在 ~/.local/share/opencode/auth.json，新版改存在本機 SQLite 資料庫 ~/.local/share/opencode/opencode.dbOpenCode 表示本機金鑰不會傳到 OpenCode 的伺服器，不在這次通報範圍內
OpenCode Console（雲端工作區）OpenCode 的雲端。管理員把各家供應商的金鑰存進去，Console 代替成員呼叫模型，成員看不到原始金鑰是。這次出事的就是這裡

Console 的設計本來就是「集中保管、代為呼叫」，好處是成員不必各自持有金鑰。代價是：只要有人讀到這份保管資料，就同時拿到每一家供應商的呼叫權，費用全部記在原本的帳號上。

事件經過

以下時間都換算成台北時間（UTC+8）。三家供應商的回應目前都來自員工的個人帳號，不是公司的正式公告。

時間（台北）發生的事
10 月 16 日晚間至 17 日OpenCode 所說的「昨晚」，有人未經授權進入一套正在退役的舊系統。精確的起訖時間尚未公布。
10 月 17 日受影響者收到主旨為 “Action Required: Potential provider key breach” 的通知信，請大家到各供應商撤銷並更換金鑰、檢查異常用量。
10 月 17 日 23:30安全研究員 Matt Johansen 貼出通知信截圖，並提到有使用者的金鑰正在被刷費用。
10 月 18 日 01:56OpenCode 官方帳號公開承認事件：影響 1.4% 的 Console 使用者，事件與大規模「蒸餾攻擊」有關，正與 Anthropic、OpenAI、Google 合作處理。02:08 編輯貼文，補上「沒收到信的人未受影響」。
10 月 18 日 05:04Anthropic 員工 Lydia Hallie：已撤銷判斷受影響的 Claude API 金鑰；曾在 OpenCode 存過金鑰的人，若想更謹慎可以另建一把。
10 月 18 日 05:38OpenCode 的 Dax Raad 澄清：出事的是 Console，不是本機的 OpenCode 程式。
10 月 18 日 06:53Google 員工 Evan Otero：已封鎖外洩的 Gemini API 金鑰；請在 AI Studio 建立新金鑰、刪除舊的、檢查用量，非本人產生的費用向 Google Cloud Billing Support 申訴。
10 月 18 日 08:01Dax Raad 表示已聯繫所有受影響者，退款正在進行。
10 月 18 日 20:04Dax Raad 表示攻擊者在過去 48 小時仍持續嘗試進入系統，各項控制正在加強。
10 月 19 日 12:12OpenAI 員工 Tibo：已協助受影響的 OpenAI API 客戶恢復服務，並退回這次攻擊消耗的 credits。
截至 10 月 19 日晚間仍沒有公開的根因報告、受影響人數、存取時間範圍或損失總額。

已確定與尚未確定的事

已經可以確定

  • OpenCode 官方承認事件，並寄出通知信。
  • 入口是一套正在退役的舊系統，可能外洩的是存在 Console 工作區的第三方供應商金鑰。
  • 本機 OpenCode 程式的金鑰不在通報範圍內。
  • Anthropic、Google、OpenAI 都有員工公開說明已採取的處置。

還不能確定

  • 攻擊者怎麼進去、從什麼時候開始、到什麼時候結束。
  • 1.4% 的母數是多少、實際影響多少人、外洩了多少把金鑰。
  • 每一把被點名的金鑰是否都被複製、被拿去用了多少。
  • 「蒸餾攻擊」和這次入侵到底是什麼關係。
  • 除了金鑰之外，提示詞、模型回答、工作區資料等是否也被接觸。通知信只提到金鑰。

一個說得通、但還沒有被證實的推論是：有人進入舊系統，取得寄放在那裡的供應商金鑰，再用這些金鑰大量詢問模型，收集回答來訓練或模仿另一個模型（也就是「蒸餾」）。這可以同時解釋「舊系統遭進入」、「金鑰可能暴露」和「蒸餾」三種說法，但目前仍只是推論。

三件容易誤會的事

  1. 1.4% 是 Console 使用者的比例。它不是所有 OpenCode 使用者的比例，也不是外洩金鑰的比例。母數沒有公布，所以換算不出人數，也不能因為比例小就覺得沒事。
  2. 「沒收到信」不等於「一定沒事」。這是 OpenCode 對自己調查範圍的結論。信件可能被擋、寄到別名信箱、寄給已經離職的帳號擁有者。企業應該用自己的資產清單核對，而不是只等通知信。
  3. 「蒸餾攻擊」目前是 OpenCode 的說法，不是已證實的入侵手法。通知信用的是 “may have been exposed”（可能已暴露）；有安全研究員則直接寫 “keys stolen”（金鑰被偷）。兩句話的確定程度不同，引用時要分清楚是誰說的。

為什麼一定要到供應商後台撤銷

API 金鑰像一把不記名的鑰匙：誰拿到就能用，費用記在原本的帳號上。鑰匙被複製之後，在原處刪掉備份，並不會讓複本失效。這次事件裡常見的三種「刪除」，效果差很多：

動作實際效果
在 OpenCode Console 移除連線之後經過 Console 的請求不再用這把金鑰，但已經被複製的金鑰仍然可以直接呼叫供應商。
在 Console 設定預算或用量上限只限制經過 Console 的流量；被複製出去的金鑰不經過 Console，限制不到。
在供應商後台撤銷金鑰這把金鑰的所有複本一起失效。但你自己正式系統裡用的同一把也會失效，所以要先找齊所有使用的地方，再撤銷。

三家供應商目前的處置

AnthropicOpenAIGoogle
已公開的處置撤銷判斷受影響的 Claude API 金鑰協助受影響客戶恢復服務，退回攻擊消耗的 credits封鎖外洩的 Gemini API 金鑰
建議使用者做的事曾存在 OpenCode 的金鑰，另建一把新的疑似外洩就撤銷並更換，檢查 Usage Dashboard在 AI Studio 建新金鑰、刪除舊的、檢查用量
費用截至截稿沒有公開的退款承諾有退回 credits 的說法，但沒有正式的申請流程非本人費用向 Cloud Billing Support 申訴
要自己再確認的事不要假設每一把都已被撤銷，自己確認並更換退款到帳前，先自己撤銷、輪替，保存紀錄只涵蓋 Gemini API 金鑰；Vertex AI 服務帳號等其他憑證要另外檢查

網路上有使用者自述被刷了數百到約 1,700 美元不等的費用，但這些數字都未經獨立查證，只能說明「確實有人觀察到異常費用」，不能加總成官方的損失金額。

應變措施：個人開發者

只要曾在 OpenCode Console 工作區存過任何供應商的金鑰，不論有沒有收到通知信，都建議照下面做：

  1. 到供應商官方網站撤銷舊金鑰、建立新金鑰。請自己輸入網址，不要點通知信或任何訊息裡的連結。
  2. 檢查 10 月 16 日到今天的用量與帳單。留下截圖、匯出檔、request ID 與時間，方便之後申訴。
  3. 依各家方式處理費用。OpenAI 先看 credits 是否已退回；Google 的非本人費用向 Cloud Billing Support 申訴；Anthropic 先確認舊金鑰是否已經不能用，再自己換一把。
  4. 找出還在用舊金鑰的地方。例如 .env 檔、shell 設定、GitHub Actions 等 CI、自動化流程，以及本機 OpenCode 的 auth.json 或 opencode.db。換成新金鑰後，把舊值刪掉。
  5. 以後每個工具用不同的金鑰，並設定到期日、較低的花費上限與用量告警。

如果確定金鑰從來沒有存進 Console，依 OpenCode 的說法就不在這次範圍內。只要有一點不確定，就換一把——換金鑰的成本，比猜錯低得多。

應變措施：企業

企業的第一個問題是：我們有沒有把任何 AI 供應商的金鑰存進 OpenCode Console？有的話，把這件事當成「第三方保管的憑證可能外洩」處理，指定一位事件負責人，並找齊資安、維運、財務、法務與各系統負責人。下面是建議的處置順序：

前 2 小時：讓舊金鑰不能再刷

  • 暫停無法確認範圍的 Console 對外連線。
  • 到各供應商後台撤銷曾存入 Console 的所有憑證。不要只處理通知信點名的 OpenAI 和 Anthropic；Gemini、AWS Bedrock、Azure OpenAI、Vertex AI 服務帳號等，只要存過都要盤點。
  • 調低各專案的花費上限與速率上限。
  • 先匯出證據再改設定：原始通知信、用量與帳單、request ID、支援案件編號。完整的金鑰不要貼進工單或聊天室，只寫末四碼。

接下來 6 小時：找齊使用處並恢復服務

  • 列出每把舊金鑰在哪裡被使用：Kubernetes Secret、CI、n8n 等自動化、Lambda、容器、本機 agent、各種 SaaS 整合。
  • 新金鑰先在測試環境驗證，再分批換到正式環境，觀察錯誤率與費用是否回到平常水準。
  • 用已撤銷的舊金鑰試打一次，確認確實被拒絕，並記錄時間與狀態碼。
  • 和事件前 14 到 30 天比較：每日費用、請求量、輸出 token、使用的模型、地區與時段有沒有異常。
  • 檢查有沒有多出新的金鑰、服務帳號、管理員、帳單或 webhook 設定，確認沒有留下第二個入口。

一天之內：劃定範圍、通知內部

  • 把帳號分成「已確認、很可能、有可能、目前看不到影響」四類。「沒收到信」只是其中一項證據。
  • 法務評估是否涉及個資或客戶資料、是否需要通報。如果這些金鑰呼叫的工作負載會處理個資或受合約約束的資料，不要直接把事件定調成「只有金鑰外洩」。
  • 財務鎖定爭議費用，分別向各供應商開立帳務案件。
  • 對內說明：哪些服務受影響、哪些憑證已更換、發現異常要通報給誰。

三天之內：避免一次被整串拿走

  • 共用的組織金鑰拆成「每個應用、每個環境、每個團隊」各一把，每把都有負責人、用途、到期日、額度與撤銷步驟。
  • 能用短期憑證或工作負載身分的地方，就不要放長期金鑰。
  • 金鑰放進有權限控管、有稽核紀錄、可以輪替的保管庫。
  • 設定模型允許清單、每日與每月的硬性預算、費用異常告警。
  • 重新檢視哪些 SaaS 可以代管正式環境的金鑰。沒有明確的保管設計、事件通知時限與事後報告義務的服務，不應代管正式金鑰。

各職能的第一步

角色現在先做的事
經營主管確認公司有沒有使用 Console；有的話，授權短暫停機換金鑰，並指定一位對外窗口。
資訊安全把事件定為憑證外洩，依「曾存入 Console 的每一種憑證」劃範圍，先保存證據再處置。
工程與維運建一張表追蹤每把舊金鑰：存在哪個供應商、哪些系統在用、何時換新、何時撤銷、撤銷後是否確實被拒絕。
財務從 10 月 16 日起對帳，把爭議費用、發票與案件編號集中保存。
法務與個資評估是否涉及個資或客戶資料；對外說法沿用「可能暴露、事件仍在進行」，不要超出目前的證據。
一般同仁小心冒名的釣魚信，不點信內連結、不把金鑰貼到聊天室或表單；曾把測試金鑰貼進 Console 的人，主動告知負責人。

這次事件給我們的提醒

  • 便利的集中保管，也代表集中的風險。一個地方保管很多把高價值的鑰匙，一次失守，就會同時出現在好幾家的帳單上。
  • 要知道自己的鑰匙放在哪裡。同一個品牌的本機程式和雲端服務，保管責任完全不同。
  • 退役中的舊系統也是攻擊面。系統退役時，要確認裡面的機密資料已經刪除或隔離。
  • 看清楚每句話是誰說的、說得多確定。官方公告、員工個人貼文、使用者自述、媒體整理的可信度不同，引用時要分開。

什麼時候才算結案

在下列資訊公開之前，建議企業持續追蹤，不要把事件標成已結束：

  • 攻擊者的進入方式，以及退役中的舊系統為什麼還能接觸到正式環境的金鑰。
  • 存取的時間範圍、受影響的憑證種類，以及如何判斷自己的帳號是否在範圍內。
  • 舊系統已經退役、資料已經刪除的證明。
  • 金鑰以外的資料（提示詞、模型回答、工作區資料、稽核紀錄）是否被接觸。
  • 各供應商撤銷與退款的範圍、期間與條件，以及防止再次發生的改善措施。

資料來源

三家供應商的回應目前都是員工的個人貼文，不是公司正式公告；使用者自述的金額也未經獨立查證。本文的應變建議參考 CISA、OWASP 與各供應商的金鑰管理指引，屬於一般性建議，實際處置請依公司自己的環境調整。

發佈留言