創辦人林沅霖在事發後第三日連發五則貼文
Zeabur 創辦人 Yuanlin 林沅霖在 2026 年 8 月 29 日早上 5 時 28 分（香港時間）於 Threads 連發五則貼文，就 8 月 27 日的環境變數洩漏事件公開說明。這是他本人自事件曝光以來首次具名發聲，距離公司偵測到異常已超過 38 小時，距離用戶收到【請立即採取行動】通知信約 12 個半小時。
第一則貼文列出公司聲稱已完成的四項處置：偵測到異常當天即完成第一時間的控制、持續監控是否有進一步異常、逐一通知所有可能受影響的使用者並發布公告、正在配合上游廠商及執法機關進行進一步調查。其餘四則分別附上技術支援頁面、憑證輪替指南，以及官方公告與調查進度頁。事件頁面本身標示的建立時間為 8 月 28 日下午 3 時 11 分，但本網在 8 月 28 日晚上 9 時 59 分查看時，狀態頁仍顯示全部服務正常；當晚事件主要靠用戶把通知信截圖貼上 linux.do 與 V2EX 擴散，而不是靠這一頁。Zeabur 的狀態頁由 Better Stack 託管，事件的申報時間可由發布者自行設定，因此頁面上的建立時間不等於它當時已經公開可見。
時間（香港時間） | 事件 |
|---|---|
8 月 27 日 | 偵測到內部服務憑證遭未授權使用，同日撤銷憑證並阻斷存取 |
8 月 28 日下午 3 時 11 分 | status.zeabur.com 建立事件頁，Dashboard 標示為 Degraded |
8 月 28 日下午 4 時 55 分 | 【請立即採取行動】通知信寄出 |
8 月 29 日凌晨 1 時 42 分 | 狀態頁更新：LiteLLM 出現可疑活動，暫停 AI Hub |
8 月 29 日早上 5 時 28 分 | 林沅霖在 Threads 發出五則貼文 |
賠償承諾附帶條件：舉證責任落在用戶一方
貼文中最受關注的一句是賠償。林沅霖寫明公司會「在完成必要的調查與核實後，盡快進行後續的賠償處理」，並在第二則貼文表示「會盡我們所能解決本次問題，妥善完成後續調查、賠償及相關處理，並對本次事件負起應有的責任」。
承諾附有一組前置條件。用戶如發現憑證遭濫用，要先自行完成輪替，再從 AI 廠商後台取得四項資料，提交至 Zeabur 技術支援頁面。
用戶要提交的資料 | 官方說明的用途 |
|---|---|
濫用請求的發生時間 | 界定損失是否落在事件窗內 |
金額或 token 用量 | 核實損失金額 |
請求來源 IP、設備號等資訊 | 整理後交予上游廠商及執法機關 |
其他能協助調查的證據資料 | 補充舉證 |
換言之，舉證責任落在用戶一方，而 Anthropic、OpenAI、OpenRouter 的後台是否願意向個別用戶提供來源 IP 與設備號，並不在 Zeabur 的控制範圍內。五則貼文沒有給出賠償金額、上限、判定準則或時間表，只承諾以最高優先級處理相關工單。
用戶數、外洩原因、入侵者身分：三題全部留白
用戶最想知道的三件事，官方到目前為止一項都未交代。
問題 | 官方目前的說法 |
|---|---|
有多少用戶或專案受影響 | 未公布任何數字，只說「完整釐清事件範圍、核實個別損失並完成後續處理仍需要一些時間」 |
內部服務憑證如何被拿走 | 未交代。公告只寫「偵測到內部服務憑證遭未授權存取」，並以該憑證查詢專案環境變數紀錄 |
入侵者是誰 | 未交代。只說正配合上游廠商及執法機關進行調查 |
官方同時重申，目前未發現 Zeabur 帳號憑證、個人資料、伺服器資料、付款或信用卡資訊遭存取的證據，但調查仍在進行。
LiteLLM 出現可疑活動 AI Hub 已暫停
新增的線索出現在狀態頁。8 月 29 日凌晨 1 時 42 分的更新寫道，調查期間發現與 LiteLLM 有關的可疑活動，該元件由 Zeabur AI Hub 服務使用，公司正在確認是否與本次事件相關；作為預防措施，AI Hub 服務暫時停用。
這是官方首次點名一個具體元件，但措辭仍停留在「正在調查是否相關」，未確認為外洩途徑。LiteLLM 是常見的大型語言模型代理層，用來統一轉發不同廠商的 API 請求，本身就經手金鑰，而被盜刷的偏偏是 Anthropic、OpenAI 與 OpenRouter 的金鑰，兩者對得上並不代表因果成立，但值得跟進調查報告怎樣寫。
輪替清單分兩批 第二批改為比對憑證格式
官方的憑證輪替指南把調查分成兩批，兩批判定條件不同。
批次 | 判定方式 | 涵蓋範圍 |
|---|---|---|
第一批 | 只比對 key 名稱 | AWS、Cloudflare、GitHub PAT、Gemini、Stripe、DigitalOcean、Linode 等 15 個變數名 |
第二批 | 名稱加值格式 | 新增 ANTHROPIC_API_KEY、OPENAI_API_KEY、OPENROUTER_API_KEY、DATABASE_URL、JWT_SECRET 等 11 個名稱，另比對 AKIA、ghp_、sk-ant-、sk-or-v1-、sk-proj-、sk_live_ 等值格式 |
第二批的存在正好對上事件初期用戶的抱怨：有人收到的通知信只提到 Stripe 密鑰，實際被刷爆的卻是大型語言模型金鑰。指南亦寫明，即使沒有收到通知信，只要專案中有上述類型的變數，仍建議一併輪替。
指南另有一項容易做錯的地方值得留意：Zeabur 託管的 PostgreSQL、MySQL 與 MongoDB，只改環境變數不會改到資料庫密碼，官方 image 只在首次初始化時讀取 POSTGRES_PASSWORD 這類變數，必須另外對執行中的資料庫下 ALTER USER 指令。指南亦提醒不要用 openssl rand -base64 產生新密碼，因為加號、斜線與等號這類符號放進連線字串會造成解析錯誤，而報錯訊息通常難以判讀。至於 Patroni 高可用叢集、ClickHouse、MinIO 與外部資料庫，官方要求交由 support 處理，不要自行操作。
No comments yet