OpenCode 安全漏洞外洩 AI 供應商金鑰，但本機安裝面臨不同風險

OpenCode 披露一宗影響 1.4% Console 用戶的安全漏洞，攻擊者存取了一個舊有系統，並可能取得已連結的 AI 供應商金鑰。這些憑證或可授權對 OpenAI、Anthropic、Google 及其他模型供應商服務發出可計費請求。

OpenCode 安全漏洞並不代表每個本機 OpenCode 安裝均已被入侵。已報告的外洩主要涉及 OpenCode Console，這是一項可選用的託管服務，可為共用工作區儲存供應商憑證。根據其文件及維護者說法，OpenCode 的本機應用程式採用不同的憑證路徑。

這項分別限制了已確認的影響範圍，但未有消除營運上的問題。安全團隊仍須找出 OpenCode 安裝項目、識別曾使用 Console 的人士、追蹤已連結憑證，以及檢視供應商活動。這宗事件令一個 AI 編碼工具變成橫跨開發人員裝置、託管工作區及外部帳單帳戶的憑證管理調查。

OpenCode 安全漏洞實際外洩了甚麼

事件核心是未經授權存取由 OpenCode Console 儲存的供應商金鑰，並非證實每個 OpenCode 用戶端均遭入侵。

OpenCode 於 2026 年 10 月 17 日披露這宗事件。公司表示曾發生與其所稱的大規模蒸餾攻擊有關的安全漏洞。它報告指 1.4% OpenCode Console 用戶受影響，並表示已透過電郵通知該等用戶。

公司向客戶發出的通知把外洩歸因於涉及一個正被淘汰的舊有系統的未經授權存取。通知警告收件人，其工作區內儲存的第三方供應商金鑰可能已外洩，並要求受影響客戶撤銷相關金鑰、予以更換及檢視近期用量。

OpenCode Console 是與這個開源編碼代理相關的託管服務。其工作區功能讓管理員連接供應商帳戶，並向其他成員提供獲批准的模型。OpenCode 的 Console 供應商文件指出，該服務會儲存供應商憑證，並在透過其閘道轉送請求時插入該憑證。

這個架構可防止一般工作區成員看見底層密鑰，但同時亦把儲存的憑證置於共同服務邊界之後。一旦該邊界失效，一宗事件便可能影響多個上游供應商的帳戶。

受影響用戶的報告提到意外的模型使用量及消費警報。部分人士表示，未經授權活動似乎出現在多於一個供應商帳戶。據報 OpenAI、Anthropic 及 Google 已著手封鎖已外洩憑證、恢復存取權限，或處理未經授權的收費。

現有報道未有提供經核實的外洩金鑰數量。OpenCode 尚未公布 Console 用戶總數，因此公司所指的 1.4% 無法換算成可靠的受害者人數。

公司亦未有公開說明攻擊者如何進入該舊有系統，亦未解釋憑證在靜態儲存時如何受保護、攻擊者繞過了哪些控制措施，或入侵者是否存取了其他工作區資料。

這些資訊缺口十分重要，因為「蒸餾攻擊」一詞描述的是被盜模型存取權的推定用途，而未必是入侵手法。模型蒸餾通常涉及收集一個模型的輸出，以訓練或改進另一個模型。被盜 API 金鑰可為該活動提供資金，但無法解釋金鑰如何被取得。

因此，最初披露只支持一個較狹窄的結論：攻擊者接觸到一個舊有 Console 系統，供應商金鑰可能已外洩，其後出現未經授權的模型使用。確切的入侵途徑，以及把該存取與模型蒸餾聯繫起來的證據，仍未披露。

獨立報道亦記錄了應對期間一項不尋常的複雜情況。OpenCode 聯合創辦人 Dax Raad 表示，一些前沿模型最初曾協助分析事件，但其後因惡意材料觸發安全控制，而拒絕處理相關請求。

OpenCode 其後獲准使用 OpenAI 的 Daybreak Blue 計劃；據報該計劃讓經審核的防禦人員可使用較不會拒絕合法安全調查的模型。這個情況為漏洞增添了第二個問題：防禦人員愈來愈依賴其安全政策可能中斷事件分析的 AI 系統。

Console 邊界改變誰會面對風險

機構必須把已確認的 Console 外洩，與本機 OpenCode 代理更廣泛的安全狀況分開處理。

OpenCode 可在本機運行，並直接連接模型供應商。其文件指出，透過舊有本機 /connect 流程新增的憑證，會儲存在 ~/.local/share/opencode/auth.json。較新的 OpenCode V2 安裝會將已儲存憑證放在本機 SQLite 資料庫，通常位於同一 OpenCode 資料目錄之下。

這些本機憑證與儲存在 Console 工作區的供應商密鑰，採用不同路徑。OpenCode 維護者 Dax Raad 表示，漏洞涉及的是 OpenCode Console，而非 OpenCode 本身。他亦表示，直接於應用程式內設定的金鑰不會傳送至公司。

這項說法很重要，但不應就此結束企業調查。資產清單很少會區分命令列工具與其可選用的雲端帳戶。開發人員可能使用本機代理、登入 Console、加入多個工作區，並隨時間連接不同供應商帳戶。

因此，一部裝有 OpenCode 的裝置未必受已報告漏洞影響。相反，開發人員可能曾透過瀏覽器或另一部已不再保留該執行檔的裝置使用 Console。單靠搜尋端點無法產生完整的受害者名單。

正確的調查單位，是以下四項紀錄之間的關係：開發人員身分、本機 OpenCode 安裝、Console 工作區及供應商憑證。安全團隊必須核對全部四項。

這對採用去中心化工具的工程機構帶來即時壓力。員工可能連接個人供應商金鑰、團隊憑證，或特定專案的服務帳戶。每種選擇都會產生不同的影響範圍。

個人金鑰可導致直接收費，並令員工的供應商帳戶面臨風險。共用團隊金鑰可影響多個應用程式。若廣泛授權的雲端憑證屬於較大的雲端專案，除了模型使用外，亦可能造成其他後果。

同樣的區別亦適用於原始碼及對話資料。目前公開報道支持儲存的供應商憑證可能外洩，但未能證實每個儲存庫、提示、本機檔案或 OpenCode 對話均被存取。

不過，調查人員不應把不確定性轉化為保證。在 OpenCode 發布詳細的事故後報告前，受影響機構應詢問該舊有系統是否包含請求紀錄、帳戶中繼資料、工作區成員資格，或其他對攻擊者有用的資訊。

OpenCode 自己的安全文件亦指出，其本機代理並未設有沙箱。權限系統可協助用戶查看及批准操作，但不提供安全隔離。OpenCode 建議在需要真正隔離時使用容器或虛擬機器。

該威脅模型與 Console 事件不同，但亦解釋了為何尋找安裝項目十分重要。即使沒有證據顯示其端點遭入侵，一個可執行 shell 指令、修改檔案及連接網絡的代理，仍值得受到審慎管治。

機構應把 Console 外洩視為緊急憑證事件，並把發現的本機代理視為更廣泛的端點及開發安全問題。將這兩項結論合併為單一說法，將會不是誇大漏洞，就是低估代理的日常權限。

如何在開發人員裝置上尋找 OpenCode

有效的發現流程會結合執行檔搜尋、程序證據、本機資料路徑、套件紀錄及身分資訊。

先詢問開發人員是否曾使用 OpenCode Console 或收到事故電郵。這種查詢比盲目掃描端點更快，亦可直接鎖定已確認的受影響群組。在作出任何變更前，保留該電郵並記錄每個被點名的工作區及憑證。

身分團隊應在單一登入紀錄、瀏覽器存取紀錄、DNS 遙測資料、安全網關事件及開支紀錄中搜尋 OpenCode 網域。這些來源可識別過往用戶及端點套件清單未能發現的純瀏覽器存取。

在 macOS 及 Linux 上，防禦人員可檢查目前 shell 是否可使用該執行檔：

首兩個指令會找出 shell 已知的執行檔路徑。版本指令可確認發現的二進位檔能否運行，但團隊應避免在鑑證收集期間執行不受信任的檔案。應改為雜湊或隔離可疑二進位檔。

運行中的程序提供另一項訊號：

程序搜尋只會顯示收集當刻正在運行的軟件，無法證明 OpenCode 從未安裝，且執行檔亦可能已被重新命名。

套件管理工具可提供歷來或目前安裝的證據。在開發人員系統上，應檢視 Homebrew formulas 及 casks、全域安裝的 JavaScript 套件、shell 安裝紀錄、受管理應用程式目錄，以及端點管理工具提供的軟件清單。

團隊應明確搜尋 opencode 執行檔，而非假設只有單一套件名稱。封裝及安裝方法可以改變，而名稱相近的專案亦可能產生誤報。

OpenCode 資料目錄比單憑執行檔更能提供有力證據。對於舊有本機安裝，請檢查已記錄的路徑：

切勿把憑證檔案內容輸出至終端機紀錄、工單或聊天室。簡單的目錄清單足以確認其存在，而不會洩露密鑰。

OpenCode V2 可透過其偵錯指令報告資料庫位置。其供應商文件指出，通常的本機資料庫路徑為 ~/.local/share/opencode/opencode.db，不過環境設定及發行渠道可能令此路徑有所不同。

在 Windows 上，防禦人員可使用內置指令尋找執行檔及運行中的程序：

用戶設定檔、套件管理工具清單、Windows 應用程式控制紀錄及端點偵測遙測資料，均可揭示額外安裝項目。應搜尋每個設定檔，而非只檢查執行掃描的帳戶。

容器化開發環境需要獨立覆蓋。搜尋已批准的開發映像、Dev Container 設定、Docker 歷史紀錄、遙距工作區及短暫的 CI 環境。對員工手提電腦進行掃描，將錯過只安裝於容器或雲端開發主機內的代理。

儲存庫搜尋可用於尋找 OpenCode 設定檔、政策參考資料或安裝指令碼。搜尋不應不加區分地蒐集原始碼或機密資料。應將範圍限於已知的設定名稱及安裝指令，然後與儲存庫擁有者核實每項結果。

Shell 歷史紀錄亦可能載有安裝或呼叫證據。這些紀錄可能包含權杖及私人指令，因此屬敏感資料。只應依照機構的事故應變及私隱程序蒐集。

偵測工作不應只回答二進制檔案是否存在。對於每項已確認安裝，應記錄使用者、裝置、版本、安裝方式、最後一次觀察到的執行時間、本機資料位置、Console 登入狀態、工作區成員資格及已連接的供應商。

最重要的問題是，使用者是否曾在受影響的 Console 工作區儲存供應商憑證。僅有本機憑證的本機安裝，並不屬於目前所述的外洩範圍。即使現時裝置上已沒有 OpenCode 可執行檔，Console 使用者仍可能需要立即輪換憑證。

OpenCode 的一般本機供應商流程支援多項服務。其本機供應商指南記載了直接憑證及以環境變數為基礎的雲端認證。這種多樣性意味著探索指令碼應尋找關聯，而不是把每個可能的機密資料複製到中央報告。

環境變數需要特別處理。變數名稱可顯示某個程序可使用哪些供應商，但其值屬於機密。偵測系統應記錄該變數存在，而不應擷取完整內容。

端點團隊亦應尋找未經驗證的 OpenCode 伺服器模式。根據該專案的威脅模型，伺服器模式屬可選功能，並應使用 OPENCODE_SERVER_PASSWORD 作 HTTP Basic Authentication。暴露於本機或遠端的伺服器構成另一項需要遏制的風險，即使它並非這次 Console 外洩的已報稱成因。

對於沒有可靠軟件資產清單的機構，這次事件正好促使其建立清單。AI 程式編寫代理是具備網絡存取能力及憑證關係的可執行開發工具。它們應納入與 IDE 擴充功能、套件管理工具、建置工具及遙距管理軟件相同的資產控制範圍。

可搜尋的技術文件系統可協助團隊保存安裝紀錄、應變決策及責任歸屬，而不會將它們分散在私人訊息中。同一原則亦適用於工程知識庫：只有當應變人員能夠擷取並連結證據時，證據才有價值。

應變始於供應商端遏制

在簽發憑證的供應商端撤銷已外洩憑證，比從儲存它的應用程式中刪除更可靠。

首先，保留通知並識別 OpenCode 所列出的每項憑證。記錄其供應商、工作區、擁有人、專案、權限、建立日期及已知相依服務。切勿將完整機密資料貼入事故紀錄。

其次，在供應商本身的控制台撤銷每條受影響金鑰。從 OpenCode 移除憑證，並不會令攻擊者已持有的副本失效。供應商端撤銷可關閉授權路徑。

第三，僅在確認舊憑證已停用後才建立替代憑證。為不同專案、環境及工具使用獨立金鑰。避免以另一項被廣泛共用的機密資料，取代一項共用機密資料。

第四，更新依賴已撤銷金鑰的合法應用程式。此步驟應與服務擁有人協調，因為快速輪換可能中斷開發環境、排程工作、測試系統及生產工作負載。

第五，從最早可能的暴露時間開始審查供應商用量。報告指潛在暴露最早可追溯至 2026 年 10 月 17 日 00:30 UTC。審慎調查應納入更早的緩衝期，並持續至確認完成撤銷為止。

留意不熟悉的模型、突發的權杖用量高峰、異常請求時間、新的來源網絡、非預期地區，以及達到預算上限的專案。將這些事件與開發活動、CI 工作及已知的自動化工作負載比較。

第六，檢查帳單及安全警示。未經授權的模型請求可能會先以開支異常的形式出現，而不是登入警示，因為 API 金鑰不需要互動式帳戶工作階段。

第七，透過官方支援或安全渠道聯絡供應商。要求其保留相關請求中繼資料、識別濫用情況、恢復被錯誤暫停的專案，並說明賠償程序。

第八，從每個 Console 工作區移除過時憑證及供應商連線。在 OpenCode 提供足夠技術資訊，讓機構風險負責人批准該決定前，切勿重新連接替代機密資料。

第九，降低未來任何被竊金鑰的價值。在支援的情況下，使用供應商端預算、速率限制、專案分隔、最小權限、到期設定、網絡限制或服務身分。

預算控制不是安全邊界。它們可限制財務損失並加快偵測，但攻擊者仍可能在預算耗盡前消耗敏感模型容量，或觸發帳戶執法措施。

第十，在不假定本機電腦造成暴露的前提下檢查本機裝置。審查 OpenCode 資料路徑、版本、活躍程序、設定及伺服器模式設定。在解除安裝軟件前，保留可疑成品。

若本機憑證從未儲存在 Console，應按證據及機構政策輪換，而不應基於所有 OpenCode 機密資料均已外洩這種未獲證實的說法。為獨立開發金鑰輪換成本不高，但不慎的大規模輪換可能造成服務中斷，並模糊事故時間線。

第十一，識別本機代理可取得的下游機密資料。經使用者批准後，OpenCode 可存取 shell 工具及專案檔案。遭入侵的供應商金鑰不會自動暴露儲存庫權杖、雲端憑證或簽署金鑰，但若端點證據顯示存在惡意指令或未經授權存取，這些資產值得審查。

第十二，監察替代憑證。新金鑰應比舊金鑰收到更嚴格的警示。調查人員需要知道可疑請求是否在輪換後停止，或透過另一個存取路徑再次出現。

第十三，記錄有關持續使用 Console 的決定。紀錄應列明負責的風險擁有人、已審閱的證據、尚未釐清的事項，以及在可再次於其中儲存憑證前所需的控制措施。

最後，在供應商活動、帳單紀錄、身分日誌及端點調查結果一致前，應保持調查開放。乾淨的手提電腦掃描無法排除 Console 憑證風險。已撤銷的金鑰無法排除暴露的本機伺服器風險。每一層回答的問題各不相同。

「蒸餾」標籤仍是事件敘述中最薄弱的一環

OpenCode 已將事件與大規模模型蒸餾聯繫起來，但公開證據尚未證實該動機或機制。

蒸餾活動可利用一個模型的輸出來訓練或改進另一個模型。大規模進行時，此過程需要大量請求，並可能產生可觀的供應商費用。遭竊的 API 金鑰可讓攻擊者使用付費推論，而無須動用自己的帳單帳戶。

這種解釋合乎情理，但合乎情理不等於可歸責。OpenCode 尚未公布請求樣本、流量模式、目標模型、攻擊者基礎設施，或其他顯示未經授權使用流入訓練管線的指標。

這個詞亦可能混淆兩項獨立行為。未經授權存取舊有系統是外洩事件。使用遭竊憑證進行高流量查詢是濫用。蒸餾只是這種濫用的一個可能目的。

安全團隊毋須在採取行動前釐清攻擊者的最終目標。無論憑證盜竊被用於蒸餾、發送垃圾訊息、基準測試、轉售或其他未經授權的推論，應變方式都一樣。

然而，該標籤對問責至關重要。將事件稱為蒸餾攻擊，可能將焦點轉向模型競爭及地緣政治存取限制。將其稱為憑證外洩，則會將注意力導向儲存、分隔、監察及淘汰舊有系統。

兩個議題都值得調查，但只有其中一項已明確確立。有紀錄的事件涉及未經授權存取舊有系統及暴露的持有者憑證。所聲稱的蒸餾關聯仍是公司定性，正等待支持證據。

該事件亦暴露 AI 輔助防禦中的衝突。據報 OpenCode 團隊在攻擊者持續探測其系統時，一直使用 AI 代理。部分模型後來拒絕分析惡意內容，因為相關請求看似被禁止的攻擊性活動。

較早前涉及 Hugging Face 的事件亦出現相似問題。防禦者認為，模型護欄無法可靠地分辨分析同一漏洞材料的事故應變人員與攻擊者。應對方法往往是轉用由本機控制或獲特別批准的模型。

這種取捨不代表限制較少的模型必然更安全。拒絕較少的模型可協助獲授權的應變人員，但亦可協助攻擊者。存取控制、審計軌跡、隔離的分析環境及經驗證的應變人員計劃仍屬必要。

因此，這次外洩令兩項承諾與營運現實互相碰撞。託管 AI 閘道承諾可更簡便地存取多個供應商，但它們可能集中存放有價值的憑證。設有護欄的模型承諾更安全的行為，但這些控制可能中斷合法的事故應變。

兩個問題都沒有單一產品層面的解決方案。機構需要假設閘道可能失效的架構，亦需要不依賴單一模型同意分析敵對程式碼的應變程序。

OpenCode 的公開威脅模型提供了有用背景。該代理可執行指令及存取檔案，而其權限提示並非沙盒。這項設計讓開發人員更靈活，但亦使身分、端點隔離及憑證範圍成為核心安全控制。

不應利用這次外洩聲稱開源代理天生不安全，或專有工具天生安全。核心問題在於憑證存放在哪裡、誰可使用、如何監察活動，以及受信任服務遭入侵時會發生甚麼。

技術事後報告將可得出更有力的結論。報告應說明初始存取途徑、受影響系統、憑證保護、暴露時段、偵測方法、攻擊者行動、遏制時間線，以及蒸餾評估背後的證據。

在此之前，買家應以清晰的證據層級評估這次事件。OpenCode 的 1.4% 範圍數字屬公司聲明。使用者報告支持確有未經授權使用。Console 架構解釋了為何已儲存的供應商憑證至關重要。攻擊者身分及確切目標仍未釐清。

三個訊號將顯示應對措施是否奏效

下一項考驗是，OpenCode 及受影響供應商能否以可驗證的證據及持久控制，取代一項緊急披露。

第一個訊號是 OpenCode 詳盡的事件後報告。報告應說明舊有系統如何仍可被存取、憑證如何儲存、哪些控制失效，以及公司為何相信該活動涉及蒸餾。

一份完整報告將有助於確認事件的影響範圍已被理解並受到限制。若在缺乏分母、根本原因或憑證數量的情況下，繼續依賴 1.4% 這個數字，將削弱這種信心。

第二個訊號是供應商一方的處理進展。OpenAI、Anthropic、Google 及其他受影響服務應能識別未經授權的請求、完成適當賠償、恢復被錯誤停權的專案，並協助客戶確認已撤銷的金鑰不再有效。

這個過程將顯示模型供應商能否就跨平台憑證事故進行協調，也會揭示現行防詐騙控制措施能否在大量可計費請求累積之前偵測到被盜用的 AI 金鑰。

第三個訊號是 OpenCode Console 內部的架構變更。使用者應留意憑證有效期是否縮短、供應商連線是否有更嚴格的隔離、稽核日誌是否改善、舊有系統是否更嚴格地淘汰，以及當金鑰出現異常行為時是否提供更清晰的警示。

這些控制措施可減少對單一已儲存 bearer secret 的依賴。若替換金鑰後的架構實質上沒有改變，眼前事故或許會結束，但潛在的集中風險仍然存在。

OpenCode 的安全漏洞並不代表每一部運行 OpenCode 的開發者電腦都遭入侵。它所證明的是，一個可選的託管層可將已連結的供應商帳戶變成共同的事故暴露面。

安全團隊應針對這項較狹窄的發現作出精準行動：找出相關安裝、確認與 Console 的關係、從源頭撤銷受影響憑證，並向各供應商核實活動紀錄。

然後提出一個更棘手的問題：你的機構是否知道哪些 AI agents 可執行程式碼、其憑證存放在哪裏，以及當其中一個信任邊界失效時，由誰負責處理？