台灣 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 點先收到官方通知信。創辦人喺聲明中表示會持續監控、逐一通知可能受影響嘅使用者，並配合上游廠商同執法機關進行進一步調查。
事件 root cause + 創辦人技術更新
創辦人林沅霖喺事件後發出更詳細嘅技術更新，以下為官方確認到嘅情況（創辦人公開聲明 verbatim）：
「攻擊者是取得了我們內部洩漏的一把 AWS 管理金鑰，進入我們位於日本東京的 AWS 共享叢集後，從叢集內部獲取到了系統控制面的 VPN 訪問權限，得以進入主資料庫。」
「從我們目前對主資料庫的紀錄進行分析，目前僅看到攻擊者對使用者的環境變數（Variables）進行了目的明確（針對 AI API Key）的定向查詢及導出。」
「對於其他敏感資料（例如客戶資料、伺服器設定等）我們從可獲取到的紀錄認為攻擊者僅進行了『不涉及具體資料』的計算數量、檔案大小等操作。」
「目前社群流傳的一篇關於『暗網』的截圖，聲稱攻擊者販售完整的 Zeabur 資料，從我們目前已經搜集的所有證據並不支持這份數據的真實性。」
「我們也已經正在與專業的第三方安全機構進行進一步的調查及分析，有任何進展仍會第一時間向各位同步。」
外洩範圍 + 已知實際被盜用嘅服務
已確認外洩嘅係環境變數中嘅密鑰，涵蓋以下類別：
- 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 日紀錄留存證據。
- 步驟 5 — 修改 SSH 密碼 + 開啟連線紀錄：如果你喺 Zeabur 部署嘅服務有用到 SSH 訪問，請即刻修改 ssh 密碼，並開啟並保留連線紀錄（login/log audit log），方便日後核實是否曾被可疑登入。
⚠️ 「撤銷」係關鍵：喺大多數 API 服務後台，「建立新 Key」唔會自動令舊 Key 失效。你必須主動去「撤銷」舊 Key，否則舊 Key 仍然可能被盜用。
點樣向 Zeabur 申請協助同舉證
如果你懷疑自己嘅 Key 已經被濫用，請先完成上面嘅撤銷同新 Key 程序，然後準備以下資料：
- 濫用發生嘅時間範圍（越精確越好）
- 受影響金額或 token 用量數字
- 請求來源 IP、設備號（device fingerprint）等 trace 資訊
- 其他能協助執法機關調查嘅證據
將以上資料提交到 Zeabur 技術支援頁面。官方表示會以最高優先級處理所有與本次事件相關嘅請求，喺完成必要嘅調查同核實後，盡快進行後續嘅賠償處理。
創辦人 Q&A：賠償、信用卡、伺服器安全
以下是創辦人喺聲明中提供嘅 5 條常見問題解答（verbatim）：
Q：Zeabur 會賠償嗎？
「我們目前已有初步的賠償執行辦法：因本次事件產生非本人操作的額外費用，我們將透過已上傳到技術支援單的資料逐筆核實，並於確認後進行賠償，目前計劃希望最遲於 9 月 30 日前完成款項安排；實際支付方式將依所在地區及個別情況而定。對於大額或情況特殊的案例，我們可能會需要更長的時間進行確認，請您見諒。」
Q：我的信用卡資料是否可能遭到盜刷？
「絕對不會，您的付款資訊是儲存在 Stripe 系統中，即使是我們內部的成員也無法取得或使用您的信用卡資料。」
Q：我部署喺 Zeabur 上嘅服務內嘅資料是否可能曾被攻擊者存取？
「從我們目前掌握到的攻擊方式，攻擊者是存在可能性、可行性進入客戶所部署的服務中存取資料。然而，如同上面所提到，我們目前沒有搜集到直接證據證明攻擊者對環境變量以外的資料。」
「如果您在環境變數內填寫了可以直接使用的資料庫憑證，且該資料庫是可以被公網直接訪問，攻擊者有可能會使用腳本工具進行嘗試存取，這是為什麼我們第一時間通知客戶輪換。」
Q：目前 Zeabur 係安全嘅嗎？
「我們在第一時間完成所有金鑰的輪換、全方位加強系統監控記錄，目前並未檢測到任何除了本次攻擊以外的可疑活動。然而，由於攻擊方式及影響範圍等因素，我們目前無法完全保證系統目前是絕對安全的。」
Q：攻擊者會入侵我喺 Zeabur 買嘅主機嗎？
「從我們目前已經確定的證據中，攻擊者並沒有存取伺服器設定相關的資料。然而，從技術上來說攻擊者當時是有查詢到主機連線方式的能力，因此仍建議您修改主機的 ssh 密碼並開啟連線紀錄。」
用戶自保 — 預防同類事件嘅最佳實踐
今次事件揭示咗 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 技術支援頁面聯絡官方團隊。
