台灣 PaaS 平台 Zeabur 喺 2026 年 8 月 27 日發生內部服務憑證遭未授權使用嘅資安事件，攻擊者透過該組憑證查詢存放專案環境變數嘅資料庫，導致用戶喺 Zeabur 設定嘅OpenAI、Anthropic、OpenRouter、Gemini、GitHub、AWS、Cloudflare、Stripe 等API Key / Token、資料庫連線字串、JWT Secret 等敏感資訊外洩。創辦人林沅霖已公開聲明確認事件，並表示將喺核實個別損失後儘快賠償。本文整理官方目前公布嘅處置、用戶應即時採取嘅補救步驟，以及坊間留意嘅LiteLLM 漏洞時序巧合。
事件時間線：8/27 發現 → 8/28 通知 → 8/29 創辦人聲明
根據 Zeabur 創辦人林沅霖嘅公開聲明同官方 status page (https://status.zeabur.com/incident/1037896) 同媒體報導（動區、INSIDE），事件時間線如下：
- 2026-08-27：Zeabur 確認一組內部服務憑證遭未授權使用，攻擊者藉此查詢存放專案環境變數嘅資料庫
- 事件當日：Zeabur 團隊已完成第一時間控制、撤銷憑證並阻斷存取
- 2026-08-28：分兩批通知受影響用戶；官方亦表明即使冇收到信都要自查，因為只要值符合已知憑證格式就可能曾暴露
- 2026-08-29：創辦人林沅霖公開道歉聲明，表示個別損失經核實後會儘快賠償
媒體報導亦提到：用戶喺 8 月 28 日凌晨先發現帳單異常並向客服查詢，下午獲回覆「無異常」，到下午約 5 點先收到官方通知信。創辦人喺聲明中表示會持續監控、逐一通知可能受影響嘅使用者，並配合上游廠商同執法機關進行進一步調查。
外洩範圍 + 已知實際被盜用嘅服務
已確認外洩嘅係環境變數中嘅密鑰，涵蓋以下類別：
- AI / LLM API：OpenAI、Anthropic、OpenRouter、Gemini
- 源代碼托管：GitHub
- 雲端服務：AWS、Cloudflare
- 付款服務：Stripe
- 資料庫連線字串（database connection strings）
- JWT Secret 等應用層密鑰
- Anthropic
- OpenAI
- OpenRouter
由於 LiteLLM 出現可疑活動，Zeabur AI Hub 已暫停服務直至另行通知，官方將喺後續公佈完整報告同賠償方案。後續進度可查 [Zeabur Status Page](https://status.zeabur.com)。
LiteLLM 漏洞時序巧合（官方未確認因果）
Zeabur 官方尚未正式確認今次事件同 LiteLLM 有直接關係。但巧合嘅係，事件發生前一日，LiteLLM 官方 GitHub 公開咗一個高風險漏洞：[GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222)。
該漏洞嘅內容：已登入嘅 LiteLLM 使用者，可能透過特製請求，令 LiteLLM 將上游 API Key（包括 OpenAI、Claude 等）洩漏出去。
如果你本身有使用 LiteLLM 做 API 中轉站：
- 立即將 LiteLLM 升級到修補版本
- 限制 api_base 等可控參數，避免暴露內部 endpoint
- 全面檢查同更換上游 API Key（OpenAI / Anthropic / OpenRouter 等）
- 查閱 LiteLLM 嘅存取紀錄，留意任何異常調用
⚠️ 注意：Zeabur 官方並未確認 LiteLLM 漏洞係今次事件嘅 root cause。現階段只能講兩件事喺時間上極接近。Zeabur 表示會喺後續完整報告中交代。
用戶應即時採取嘅 4 步
如果你曾經將 API Key 或雲端權杖放喺 Zeabur 嘅環境變數，（不論有冇收到 Zeabur 通知信），請即刻做以下步驟：
- 步驟 1 — 撤銷舊 Key：到原服務商（OpenAI / Anthropic / OpenRouter / GitHub / AWS / Stripe 等）後台撤銷受影響嘅 Key。撤銷唔可以只靠喺 Zeabur 刪除環境變數，因為舊 Key 仍然有效。
- 步驟 2 — 建立新 Key：喺原服務商後台建立新嘅 Key，再貼返去 Zeabur 嘅環境變數。
- 步驟 3 — 檢查用量同帳單：登入原服務商後台，查詢過去 7 日嘅 API 用量、token 消耗、賬單。留意有冇突然飆升或者陌生 request pattern（例如陌生 prompt、深夜時段用量異常）。
- 步驟 4 — 查存取紀錄：原服務商如果提供 request log（例如 OpenAI Usage、Anthropic Console），下載過去 7 日紀錄留存證據。
⚠️ 「撤銷」係關鍵：喺大多數 API 服務後台，「建立新 Key」唔會自動令舊 Key 失效。你必須主動去「撤銷」舊 Key，否則舊 Key 仍然可能被盜用。
點樣向 Zeabur 申請協助同舉證
如果你懷疑自己嘅 Key 已經被濫用，請先完成上面嘅撤銷同新 Key 程序，然後準備以下資料：
- 濫用發生嘅時間範圍（越精確越好）
- 受影響金額或 token 用量數字
- 請求來源 IP、設備號（device fingerprint）等 trace 資訊
- 其他能協助執法機關調查嘅證據
將以上資料提交到 Zeabur 技術支援頁面。官方表示會以最高優先級處理所有與本次事件相關嘅請求，喺完成必要嘅調查同核實後，盡快進行後續嘅賠償處理。
用戶自保 — 預防同類事件嘅最佳實踐
今次事件揭示咗 PaaS 平台「集中式管理環境變數」嘅固有風險：一旦平台嘅內部憑證被入侵，所有用戶嘅金鑰都可能同時暴露。以下係可即時採用嘅自我保護措施：
- 金鑰唔好長期放喺單一平台：能夠喺本機或自己嘅 secret manager（例如 1Password、AWS Secrets Manager、GCP Secret Manager）就唔好放平台
- 為每個服務設扣款上限：OpenAI 同 Anthropic 都支援硬性 budget cap，發現用量異常可以即時 cut off
- 定期輪換 Key：每 90 日輪換一次 API Key，減低單次外洩嘅暴露窗口
- 喺 AI 廠商後台啟用 IP 白名單：限制 API Key 只能從指定 IP range 訪問
- 為每個服務建立獨立 Key：唔好用同一個 Key 行晒所有服務，方便出事時快速 revoke
- 設定用量 alert：用量超過閾值時自動 email / SMS 通知
對開發團隊嚟講，更進一步嘅做法：短期 — 環境變數嘅 Key 加密儲存（Zeabur 之類嘅平台應該原生支援 KMS-style encryption）。中期 — 採用 zero-trust secret retrieval，例如 HashiCorp Vault、AWS Secrets Manager。長期 — 推動 SaaS 供應商將 API Key 改成 short-lived token（例如 OAuth-style），減少靜態密鑰嘅暴露風險。
創辦人林沅霖公開聲明
以下是創辦人林沅霖喺 8 月 29 日發出嘅聲明原文（節錄）：
「大家好，我是 Zeabur 的創辦人 Yuanlin 林沅霖。關於昨日發現的 Zeabur 環境變數洩漏資安事件，目前我們已經完成以下處置：在偵測到異常的當天即完成第一時間的控制；持續監控是否有進一步異常；逐一通知所有可能受影響的使用者並發布公告；正在配合上游廠商及執法機關進行進一步調查。」
「若您已經收到我們的通知信，或您目前在 Zeabur 上仍存有OpenAI、Anthropic、OpenRouter 等第三方 AI 服務的 API Key，敬請盡快根據下方輪換教學進行操作，並立即檢查您的用量及帳單。」
「如果您發現憑證已遭濫用，請先立即完成憑證輪替，並檢查相關服務的用量與帳單，並請協助我們從 AI 廠商後台取得濫用請求的：發生時間、金額或 token 用量、請求來源 ip、設備號等資訊，以及其他能協助我們與執法機關調查的證據資料。」
「請將所有能協助我們配合執法機關調查及核實您損失情況的資料提交至 Zeabur 技術支援頁面，我們會以最高優先級處理所有與本次事件相關的請求，並在完成必要的調查與核實後，盡快進行後續的賠償處理。」
結論：後續發展同官方 status link
今次事件再次提醒我哗：將 API Key 放喺第三方 PaaS 平台嘅環境變數，本質上等於將所有金鑰放喺同一個保險箱。保險箱一旦被攻破，所有用戶同時受影響。
Zeabur 事件嘅完整根因、受影響人數、賠償時程同最終事故報告，官方表示會喺後續公布。讀者可以通過以下渠道追蹤最新進度：
- Zeabur 官方 Status Page：[status.zeabur.com](https://status.zeabur.com)
- Zeabur 事件編號：[incident/1037896](https://status.zeabur.com/incident/1037896)
- LiteLLM 漏洞詳情：[GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222)
- 媒體報導：動區、INSIDE
如發現可疑用量或需要就損失個案提交資料，請儘快到 Zeabur 技術支援頁面聯絡官方團隊。
