Zeabur 的資安事件已經從「可能有風險」進入使用者必須實際止損的階段。官方狀態頁證實，一組內部服務憑證遭未授權使用，攻擊者藉此取回部分專案環境變數；最新更新則顯示，約 63% 已送出的補償申請完成驗證並進入處理，另有約 21% 仍在審查。
環境變數裡放的往往不是一般設定，而是 OpenAI、Anthropic、AWS、GitHub、Cloudflare、Stripe 等服務的 API Key、Access Token，還可能包含資料庫連線字串、JWT Secret 與 SSH 憑證。這些值一旦被看見，Zeabur 撤銷自己的內部憑證也不會讓使用者的舊金鑰自動失效。
收到影響通知的人，處理順序應該是先到金鑰原本的發行平台撤銷舊值，再建立新值、更新 Zeabur 變數並重新部署。完成後還要檢查 AI 用量、雲端帳單、GitHub 存取、資料庫登入與 Stripe 等服務的異常紀錄。只在 Zeabur 後台改成另一組字串，卻保留舊 Key，風險仍然存在。
官方目前表示，沒有證據顯示 Zeabur 帳號憑證、完整信用卡資料或其他核心後端服務遭到存取；對使用者部署服務內資料的存取，也尚未發現大規模讀取或匯出的直接證據。不過官方同時承認，在攻擊者當時取得的權限下，部分查詢在技術上不能完全排除，因此有管理伺服器的人還要輪替 SSH 金鑰並檢查近期登入。
LiteLLM 在調查期間被發現有可疑活動，Zeabur 曾預防性暫停 AI Hub，但官方尚未確認兩者就是同一條入侵路徑。這個邊界不能省略，因為目前完整時間線、根因與修補措施仍要等第三方鑑識完成。
我的判斷是，這次事件最值得記住的不是「環境變數也會外洩」，而是平台代管的秘密一樣需要可撤銷、可追蹤與定期輪替。對小團隊而言，先把金鑰權限縮小、分開正式與測試環境，再建立用量告警，會比只相信某個欄位標示為 Secret 更實際。
資料來源：Zeabur 官方事件頁、TechRitual
