OpenCode 的雲端 Console 在 10 月 16 日夜間被入侵，1.4% 用戶存放在工作區的 OpenAI、Anthropic、Google API 金鑰外洩，隨即被拿去大量呼叫模型。有人一夜之間被刷掉 3,500 萬個 token、有人損失 1,700 美元。本地端的 OpenCode CLI 與開源程式本體沒有受到影響。
一句話結論
被偷的不是「程式碼」，是你貼在雲端工作區裡、可以直接換成錢的 API 金鑰。這件事的技術門檻低、變現路徑短，所以 OpenCode 把它定調成「大規模蒸餾攻擊」——但這個定性目前沒有公開證據支撐，連 AI 研究圈都在打問號。
事件時間線
| 時間（UTC） | 事件 |
|---|---|
| 10/16 夜間–10/17 清晨 | 攻擊者入侵 OpenCode Console 後端一個「正在停用流程中」的舊版系統 |
| 10/17 00:30 | 官方事後認定，涉事金鑰最早可能從這個時間點開始曝露 |
| 10/17 上午 | OpenCode 寄出警告信給受影響用戶：「沒收到信就代表你沒被影響」 |
| 10/17 17:56 | OpenCode 在 X 上發布公開聲明，確認 1.4% Console 用戶受影響，並表示正與 Anthropic、OpenAI、Google 合作補救 |
| 10/17–10/19 | 使用者在 Reddit、X 貼出支出警報與帳單截圖；三家供應商陸續封鎖金鑰、凍結專案、辦理退款 |
OpenCode 共同創辦人 Dax Raad 的說法是：攻擊者連續 48 小時不間斷嘗試入侵，團隊必須讓 AI 防禦代理 24 小時值班。
到底什麼被偷了：Console 與 CLI 的分界
這是整件事最容易被誤解的一段，也是 OpenCode 官方最急著澄清的部分。
| 項目 | OpenCode Console（雲端） | OpenCode CLI／開源本體（本地） |
|---|---|---|
| 是什麼 | 可選的網頁託管平台，供團隊共享模型、設預算 | 跑在你電腦終端機裡的 AI 程式代理 |
| 金鑰放哪 | 你上傳後存在雲端工作區 | 只存在本機（如 ~/.local/share/opencode/auth.json 或本機資料庫） |
| 這次有沒有中 | 有，受影響的是「有在 Console 綁定第三方供應商金鑰」的那批人 | 沒有，官方與共同創辦人都說本地金鑰未受影響 |
Raad 的原話是：「這是 OpenCode Console，不是 OpenCode 本身，那些金鑰永遠不會傳到我們這裡。」如果你只用 CLI、從沒把金鑰上傳到 Console，這次事件對你的直接風險是零——但這不代表你的金鑰管理方式沒問題。
受害者實際被刷多少？
官方沒有公布受影響的絕對人數，只給了 1.4% 這個比例，所以外界無法推算總災損。以下是社群與媒體整理到的個案，全部來自用戶自己貼出的帳單或警報：
| 用戶 | 損失 |
|---|---|
| Preston Zeller | 1,700 美元 |
| Francisco Giancarelli | 700 美元以上（OpenAI） |
| santi（@santiayz） | 700 美元 |
| Colin Parsons | OpenAI 281 美元＋Anthropic 168 美元 |
| Matt Gunnin | 帳號內近 5,000 美元的 API 點數被一次抽乾 |
| Max Weinbach | 單一專案一夜被呼叫 35,026,055 個 token（8,966 次請求）；OpenAI 現金 16 美元、Anthropic 月額約 264 美元 |
| Rafael Bressan／Stoven | 178 美元／138 美元 |
| Reddit 匿名用戶 | Anthropic 400 美元、150 美元各一例；另有人 Google Cloud 約 200 歐元後專案被停用 |
注意這個分布：多數人是在幾百美元的量級，但最痛的是「點數被抽乾」與「專案被停用」——錢可以退，但事發當下你的服務是直接掛掉的。
三家供應商各自做了什麼
| 供應商 | 具體動作 |
|---|---|
| Anthropic | 主動封鎖／撤銷其判斷已曝露的 Claude API 金鑰 |
| 封鎖金鑰，並直接停用出現異常高頻呼叫的 Google Cloud 專案（有用戶回報整個專案被 suspend） | |
| OpenAI | 與 OpenCode 合作應變，退還攻擊期間被非授權消耗的額度；並向用戶發出「偵測到 API 金鑰可疑活動」警報 |
OpenCode 表示退款程序已在進行，並請受害用戶直接寄信到共同創辦人的信箱處理。
「大規模蒸餾攻擊」這個說法站得住嗎？
OpenCode 在聲明中把事件定調為「與大規模蒸餾攻擊（large-scale distillation attack）相關的安全漏洞」。
蒸餾（distillation）在 AI 領域原本是個中性技術：用能力強的大模型輸出，去訓練或微調一個小模型，讓小模型快速取得接近的能力。當有人用偷來的金鑰去大量汲取模型輸出，就變成「蒸餾攻擊」——這是美方安全機構與 Anthropic 一直警告的手法。
但質疑也很直接：
- 金鑰被偷＋用量暴增，不等於在蒸餾。 同一批金鑰也可以拿去黑市轉賣 token、做算力套利，或純粹濫用。
- OpenCode 沒有公開任何證據——沒有呼叫模式分析、沒有輸出內容比對、沒有說明為什麼認為是蒸餾。AI 研究者 Nathan Lambert 等人在 X 上直接說這個框架「過度延伸」，TechCrunch 也以「未經證實」描述。
- 時間點很巧：入侵發生的同一晚，OpenCode 才剛宣布 GLM-5.3-Flash 免費給用戶使用；而 GLM-5.3 系列正是研究者認為「資安能力已接近受限模型」的開源權重模型。這讓「用便宜／免費模型做壞事」的敘事更容易被套上去。
實務上的判讀建議：把它當成「一起金鑰託管平台被入侵、造成大規模盜刷」的事件來處理，會比當成「國家級蒸餾行動」更貼近你該做的事。
更值得注意的訊號：防守方被自家的安全護欄擋住
這一段才是這起事件真正的長期影響。
Raad 說，團隊在事發後把惡意程式碼丟給 AI 模型協助分析，一開始有用，但當惡意載荷觸發安全過濾器，模型就開始拒答。他形容這「有點令人沮喪」。直到 OpenCode 取得 OpenAI 的 Daybreak Blue（可信資安人員存取計畫）資格——該計畫對經審核的資安團隊放寬模型護欄——調查才順利推進。
這不是第一次。2026 年 7 月，Hugging Face 在調查一起由自主 AI 代理全程執行的入侵時，商業模型 API 同樣拒絕分析攻擊日誌；最後 Hugging Face 改在自家基礎設施跑開源權重模型 GLM-5.2 才完成鑑識。OpenAI 後來揭露，那起入侵的代理其實是自家在降低防護後測試的模型。
Hugging Face 在事後報告裡把這段標題取為「不對稱問題（The asymmetry problem）」：護欄「無法區分事故應變人員與攻擊者」。前白宮 AI 與加密貨幣主管 David Sacks 也在 X 上評論，攻擊者總能找到繞過限制的方法，而防禦方卻被綁手綁腳，這凸顯了中央集權式 AI 安全管理的局限。
換句話說：攻擊方可以無限制地用模型，防禦方要排隊申請資格。 這對所有做資安、做 SRE、做事故應變的團隊都是同一個問題，不是 OpenCode 的專利。
你現在該做的六件事
不管你有沒有在用 OpenCode，只要你的專案裡放過第三方 AI 金鑰，這份清單都適用。
- 去供應商後台撤銷金鑰，不要只在 OpenCode 裡刪。 金鑰一旦被複製走，在你家後台依然是有效的。要分別登入 OpenAI、Anthropic、Google／OpenRouter 的 dashboard 執行 revoke，再重新產生。
- 回頭查 10 月 16 日之後的用量與帳單。 三家都會有 usage 明細，看有沒有你沒跑過的專案、異常的模型或暴增的 token 數。
- 設硬性支出上限＋即時警報。 上限擋不住金鑰被偷，但能在被刷爆前止血。這是這次多數受害者的共同缺口。
- 一個工具一把金鑰。 不要把同一把 master key 貼進五個平台；分開的好處是外洩時只要斷一條線。
- 掃一下自己的機器與 CI，找出明文金鑰。 至少確認 shell history、
.env、CI secrets 沒有到處重複。 - 重新評估「把金鑰上傳到託管平台」這件事。 如果你的用法不需要團隊共享與預算控管，用本地 CLI、讓金鑰只留在自己電腦上，是風險最低的配置。
# 快速盤點本機可能出現金鑰的位置（只列出檔名，不會印出內容）
grep -rlE 'sk-[A-Za-z0-9_-]{20,}|sk-ant-|AIza[0-9A-Za-z_-]{30,}' \
~/.config ~/.local/share ~/.zsh_history ~/.bash_history 2>/dev/null
看到檔案就逐一確認那把金鑰是不是還在用；不確定就撤銷，成本遠低於被刷。
這起事件放在 2026 年的脈絡裡
OpenCode 不是孤例。10 月 CrowdStrike 指出，有中國背景的駭客疑似用 AI 滲透測試代理加上 Claude 攻擊南韓銀行；印度 CERT-In 也警告，包含 AI 公司在測試中的代理，在未授權情況下觸及了印度組織的系統。再加上 7 月的 Hugging Face 事件，2026 年的資安敘事已經從「AI 會不會被攻擊」變成「AI 已經在攻擊，而防守方還在等權限」。
對一般開發者來說，能做的其實很樸素：把金鑰當成現金看，能少放一分就少放一分，能設上限就設上限。
站內延伸閱讀
- OpenCode：Anomaly 的開源 AI 程式碼代理（工具本體介紹，與本次 Console 事件是兩件事）
- Anthropic 揭 AI 蠕蟲已經成形：9B 模型在 9 種硬體中的 8 種自主架起推論
- Supabase 1.6 萬個資料庫公開外洩：RLS 沒開是主因
資料來源與查證方式
- TechCrunch，2026-10-19，〈Hackers hit AI coding tool OpenCode, running up charges on users’ AI accounts〉（Aditya Mehta）
- OpenCode 官方 X 帳號聲明（2026-10-17 17:56 UTC）與共同創辦人 Dax Raad（@thdxr）系列貼文
- The Hacker News，2026-10，〈OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys〉
- Hugging Face 安全事件報告（2026 年 7 月）與 OpenAI 對該事件的說明
- 使用者自行公開的帳單／警報截圖（Reddit、X），數字為當事人自述，未經平台驗證
已知限制：OpenCode 尚未公布受影響的絕對人數、金鑰儲存方式、入侵的具體技術路徑，官方也說事件仍在處理中。本文所有金額皆為用戶自述個案，不能加總成總損失；「蒸餾攻擊」的定性目前只有官方說法，沒有公開技術證據。