OpenCode 外洩事件：用 Synthorai Trusted IPs 阻擋遭竊 API 金鑰

2026 年 10 月 17 日，OpenCode 通知使用者，入侵者存取了其代管服務 OpenCode Console 背後的一套舊系統，儲存在其中的第三方供應商金鑰「可能已外洩」。隨後有使用者回報，自己的 OpenAI、Anthropic 和 Google 帳戶出現數百美元至 $1,700 的費用。供應商金鑰就是向 OpenAI 或 Anthropic 取得的 API 金鑰；將金鑰存放在代管工具中，讓工具代為呼叫供應商，稱為 BYOK（bring your own key，自備金鑰）。金鑰外洩會造成多少損失，取決於兩件事：可以從哪些位置使用，以及在遭到阻擋前能花掉多少錢。

TL;DR

• OpenCode 表示，Console 入侵事件影響了 1.4% 的 Console 使用者；儲存在本機 OpenCode CLI 的金鑰不受影響。
• 閘道的 IP 規則和支出限制只能管到經過閘道的流量，因此供應商金鑰外洩時，仍需要供應商端的強制上限。
• 啟用 「新 IP 須核准」 後，若來源位址尚未獲得該金鑰的核准，Synthorai 會拒絕 API 呼叫，傳回 HTTP 403 和 ip_not_trusted。
• 每把 Synthorai 金鑰都可以設定支出上限、每分鐘請求與 token 上限，以及到期日。

OpenCode Console 入侵事件發生了什麼事？

OpenCode 寄給受影響使用者的郵件指出，未經授權的第三方存取了「我們正在汰除的一套舊系統」，可能讀取了這些使用者存放在 Console 工作區中的供應商金鑰。OpenCode 認定最早可能外洩的時間是 10 月 17 日 00:30 UTC。以下依 OpenCode 貼文、供應商員工貼文及媒體報導整理事件經過：

蒸餾攻擊是大量蒐集某個模型的回答，用來訓練另一個模型；這類行動可能使用遭竊金鑰支付呼叫費用。OpenCode 尚未說明這起入侵與蒸餾有何關聯。共同創辦人 Dax Raad 表示，事件涉及的是「OpenCode Console，而非 OpenCode 本身」，在本機 CLI 加入的金鑰從未傳到公司端。截至 10 月 21 日，OpenCode 尚未公布根本原因、儲存的金鑰是否加密、1.4% 對應的受影響帳戶數、退款政策或事後檢討報告（The Hacker News、BleepingComputer）。

哪些金鑰外洩了？哪些防護措施有用？

這次外洩的是供應商金鑰。攻擊者取得供應商金鑰後，會直接呼叫供應商，不會經過原本儲存金鑰的工具，因此 LLM 閘道能做的事有限。閘道位於你的程式與模型供應商之間，負責轉送請求，所以只能看見並限制經過它的流量。這裡需要區分兩種金鑰：

接下來兩節的 Trusted IPs 與支出上限，保護的是第一列的情況。第二列則要靠你在 OpenAI、Anthropic 或 Google 設定的強制上限兜底；後面的章節會列出這些設定。

Synthorai 如何保護平台金鑰與 BYOK 金鑰？

加入 BYOK Vault 的供應商金鑰，會以標準的驗證式加密演算法 AES-256-GCM 加密儲存。儲存後，任何 API、MCP 工具或主控台頁面都不會再傳回完整金鑰，主控台只顯示最後四個字元。閘道只會在處理需要該金鑰的請求時，於記憶體內解密；也只有工作區擁有者能新增、輪替或移除金鑰。Synthorai 用於提供自有服務容量的供應商金鑰也採用相同方式儲存，任何主控台頁面或 API 都不會顯示，管理員主控台也不例外。加密可以保護資料庫副本，但執行中的服務一旦遭入侵，攻擊者仍可能在金鑰使用期間取得它。因此，下文的供應商端限制仍是 BYOK 金鑰的最後一道防線。

Synthorai 核發給你的 API 金鑰只會以雜湊值儲存。這是無法還原金鑰的單向指紋。完整金鑰只在建立時顯示一次，之後無論從主控台、管理 API 或 MCP 伺服器讀取，都只會傳回前綴。推論金鑰只能呼叫模型，不能做其他事：管理 API 會拒絕這類金鑰，因此即使推論金鑰遭竊，也無法用來讀取日誌、用量或其他金鑰 (API keys, admin keys)。

Trusted IPs 如何阻擋外洩金鑰？

Trusted IPs 會拒絕來自未獲該金鑰核准位址的 API 呼叫。因此，金鑰即使從 CI 日誌或筆電被複製出去，從其他位置使用時也只會收到錯誤，拿不到模型回答。擁有者或管理員可在 Settings › Security 啟用 「新 IP 須核准」。對話框會列出過去七天各把金鑰的呼叫來源位址，並預先全部勾選為核准。確認前請逐一檢查，取消勾選不認識的位址：如果金鑰已外洩且遭到使用，攻擊者的位址也會出現在清單中。

啟用後，來自新位址的呼叫會收到 HTTP 403（以下位址為文件範例）：

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

金鑰建立者會收到電子郵件，內含來源位址、位置、用戶端及請求的模型。核准必須登入主控台操作，轉寄郵件本身不會核准任何位址。對於位址會變動的用戶端，可以核准單一位址，或其所在的 /24 網段（256 個相鄰的 IPv4 位址）。閘道會從連線取得自家代理伺服器所見的呼叫端位址，因此用戶端無法自行傳送 X-Forwarded-For 標頭來冒用其他位址；這個標頭原本是供代理伺服器傳遞原始用戶端位址使用。我們用偽造標頭測試過，拒絕回應中列出的仍是真實位址。

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

建立金鑰時也可以設定固定的 ip_allowlist，但這份清單屬於金鑰設定的一部分：每增加一個辦公室、伺服器或 VPN 出口，都得修改金鑰設定；忘記移除的項目則會一直保持開放。Trusted IPs 以金鑰現有的呼叫來源為起點，遇到新位址時先要求核准，並將各把金鑰的位址集中在同一份清單中，已知位址只要點一下就能信任。如果金鑰設有自己的允許清單，就只會依該清單判斷，因此每把金鑰應擇一使用。

信任設定以個別金鑰為單位。若 serverless 函式或 CI runner 每次執行都從新位址呼叫，每次都會等待核准。不要直接信任代管 CI 供應商公布的網段：這些位址由該供應商所有客戶共用，任何人在那裡執行工作都能通過檢查。應讓這類呼叫端經由固定出口位址連線，例如自架 runner 或 NAT 閘道，再信任該位址；或給它們一把效期短、額度低的金鑰。

支出上限如何控制金鑰遭竊的損失？

每把 Synthorai API 金鑰都能設定獨立的支出上限，即使金鑰仍然外洩，支出也會在你設定的金額停止。建立金鑰時，可在主控台設定上限、允許的模型及到期時間：

個別金鑰的速率限制及下列其他設定，可透過管理 API 設定：

以下使用管理員金鑰，為單一服務建立一把只具備該服務所需權限的金鑰。管理員金鑰可建立金鑰及設定限制，但不能呼叫模型：

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

工作區擁有者也能為每位成員設定每日及每月支出上限；成員達到每月上限後，會收到 HTTP 402，直到下個月。這些限制只適用於經過 Synthorai 的流量。若將 BYOK 計入上限，透過閘道發出的 BYOK 請求也會受到限制，但無法限制外洩後直接向供應商使用的金鑰。

這些措施擋不住什麼？

Trusted IPs 能阻擋從新位置使用金鑰的請求，但金鑰若是在受信任的機器上使用，就不會被擋下。最常見的竊用情況恰好就發生在這裡：開發者筆電上的惡意軟體、遭入侵的 CI 工作，或被誘導替攻擊者發送請求的伺服器。面對這些情況，能控制損失的是金鑰的支出上限、模型清單與較短的效期。

核准由人決定，因此攻擊者可以觸發一筆等待核准的請求，賭使用者會習慣性地按下核准。核准頁會顯示位址、位置、用戶端與模型；只有在這些資訊都符合你發出的呼叫時才核准。

每天重設的支出上限，代表遭竊金鑰在被發現前，每天都能花到上限。限制必須搭配偵測：每個待核准位址的通知郵件、主控台中的個別金鑰支出，以及金鑰異動的稽核日誌。懷疑金鑰外洩時，請在主控台刪除並建立替代金鑰。若要在外洩前攔下金鑰，可在程式碼代管平台加入 sk-syn- 前綴的機密掃描規則，例如啟用推送保護的 GitHub 自訂模式。

BYOK 金鑰應在供應商端設定什麼？

每個工具都應使用獨立的供應商金鑰，放在各自的專案或工作區中，並設定強制支出上限。這樣即使一把金鑰外洩，也只能花掉該專案的預算。外洩金鑰必須到供應商的管理介面撤銷：從儲存金鑰的工具中刪除，並不會撤銷金鑰。這三家供應商都不提供單一金鑰的支出限制，最小設定單位是專案或工作區：

只寄送電子郵件的支出警示與預算，無法阻止正在進行的攻擊。仍可保留這些通知，作為強制上限之外的第二道偵測訊號。Synthorai 主控台的 BYOK 頁面會在金鑰下方提供各供應商的上限設定連結：

OpenCode 可以搭配 Synthorai 使用嗎？

可以。本機 OpenCode CLI 使用的金鑰會留在你的電腦上，這次入侵未影響這種使用方式。執行 opencode auth login https://synthorai.io 後，OpenCode 會透過瀏覽器搭配一次性代碼完成登入，並取得一把專屬 API 金鑰，效期可選 7、30 或 90 天（設定說明）。如果已啟用 「新 IP 須核准」，且你從相同網路允許登入，登入來源位址就會自動成為該金鑰的受信任位址，其他位置的呼叫則需等待核准。若登入請求與瀏覽器來自不同網路，確認頁會顯示警告，該位址必須等到首次呼叫獲准後才會受到信任。如果不是你自己執行的指令，請取消請求。

這把金鑰會以「OpenCode」的名稱出現在 API 金鑰頁面，你可以在那裡新增支出上限或刪除金鑰。保存在筆電上的金鑰仍可能被該筆電上的惡意軟體竊取，因此建議選擇 7 或 30 天效期，並保持啟用 「新 IP 須核准」：金鑰即使被複製，從其他位址使用也會失敗，而且很快就會到期。

常見問題

儲存在 OpenCode CLI 的金鑰是否在這次事件中外洩？

沒有。OpenCode 表示，入侵範圍僅限 OpenCode Console；透過本機 CLI 或桌面應用程式加入的金鑰，都儲存在使用者的電腦上，從未傳送給 OpenCode。

從代管工具刪除供應商金鑰，是否等於撤銷金鑰？

不是。從工具刪除金鑰，只會移除工具持有的副本；金鑰在供應商端仍可使用。你必須到供應商的管理介面撤銷金鑰，再建立新的金鑰。

閘道的支出上限能否保護已外洩的供應商金鑰？

不能。閘道的限制只計算經過閘道的請求；外洩的供應商金鑰會被直接用來呼叫供應商，因此真正適用的是供應商自己的支出上限。

相關文件：Trusted IPs、BYOK Vault、管理員金鑰與金鑰限制、OpenCode 設定。

資料查閱日期為 2026 年 10 月 21 日：包括媒體引用的 OpenCode 貼文與電子郵件、供應商員工貼文，以及上方連結的供應商文件。偽造標頭測試於 2026 年 10 月 21 日針對 Synthorai 正式環境閘道執行。

← 返回部落格