「凌晨收到信用卡異常止付通知。連續多筆 API token 扣款，短時間內衝到平常單日用量的近十倍。」
8 月 28 日，一位自述有 25 年開發資歷的工程師在社群平台 Threads（帳號 @lidien.fu）貼出這段經過。他說第一個念頭是懷疑自己犯錯，查完 log 才確認該防的都防了，破口指向某個台灣新創雲端平台。
那個平台是 Zeabur。同一天，Zeabur 在官方事件頁公告，一組內部服務憑證遭未授權存取，被用來讀取使用者專案裡的環境變數（Variables）。白話來說，就是一批用戶存放在平台上、用來串接 OpenAI 與 Anthropic 等 AI 服務的 API Key 落到了別人手上，而且有人拿去用了。
Zeabur 出了什麼事？
Zeabur 是一家瞄準 Vibe Coding 風潮的一鍵部署公司。所謂 Vibe Coding，是用自然語言指揮 AI 產生程式碼，寫的人不一定看得懂那些程式碼；Zeabur 要解決的就是這群人的下一關：程式寫好了，怎麼讓它真的跑在網路上。
以下時序依官方事件頁與創辦人 Threads 說明整理，時間統一換算台灣時間；本文引述的官方說法均以 Zeabur 8 月 30 日公告為準。
8 月 27 日：Zeabur 表示偵測到一組內部服務憑證遭未授權存取，並在同一天完成控制、撤銷該憑證、封鎖存取路徑。
8 月 28 日：發布首則公告，列出已確認外洩的環境變數名稱，並逐一通知可能受影響的使用者。當天林沅霖在 Threads 說明處置進度，公布憑證輪替指南與工單管道。
8 月 29 日：Zeabur 表示在調查中發現旗下 AI Hub 所用的 LiteLLM 出現可疑活動，暫停該服務；同日發布調查更新，首度公開攻擊路徑與資料存取行為。
8 月 30 日：再度更新，修正攻擊路徑描述、公布賠償進度，並警告有人利用事件資訊行騙。
創辦人怎麼說？
事件公開當天，Zeabur 創辦人暨執行長林沅霖（Yuanlin Lin）在 Threads 說明處置：異常偵測當天即完成第一時間控制與監控，並配合上游廠商與執法機關調查。 他要求仍存有 OpenAI、Anthropic、OpenRouter 等 AI 服務金鑰的使用者盡快輪換並檢查用量與帳單。
「非常抱歉造成大家的損失及困擾，也謝謝大家長期以來對 Zeabur 的支持。」他在同一串貼文中寫道，「我們會盡我們所能解決本次問題，妥善完成後續調查、賠償及相關處理，並對本次事件負起應有的責任。」
賠償是進度最明確的一塊。截至 8 月 30 日公告，已提交的申請約 63% 完成核實、進入賠償處理，21% 仍在核實中，其餘少部分需補件。Zeabur 表示工單會盡量維持在 12 至 24 小時內回覆，並計畫在 2026 年 9 月 30 日前完成已核實案件的付款安排；金額較大、資料不完整或需第三方查核的案件可能更久。
目前爭議在暗網。據《動區動趨》報導，8 月 29 日暗網論壇出現販售文，賣家宣稱握有壓縮後 612GB 的 Zeabur 資料，包含原始碼、資料庫與 AWS 金鑰等，未經第三方驗證。但對此 Zeabur 回應，依已掌握的證據沒有找到支持該說法的依據，也無法查證截圖來源與真偽，已列入調查。
受災戶那一天：先被告知「沒有異常」，再收到外洩通知信
回到開頭那位工程師。依他 8 月 28 日的公開發文，他發現異常後向平台與 Anthropic 分別去信、申請調閱 log，同時向發卡行申請盜刷認定與停卡。兩小時後客服回覆，他的帳號在 48 小時內沒有異常存取紀錄，只有他自己作廢舊憑證的操作，請他「多加注意」。到了下午五點，他收到官方信，說明發現一個內部憑證外流、可能影響部分專案的環境變數，請用戶自行更換。
「又好氣又好笑，」他寫道，「順序是我先提報，接著被告知完整測試後沒有異常，然後再收到一封信說他們主動修補了漏洞。」
他接著寫：「我運氣好，發現得早、發卡行 carry、原本架構也有該有的基礎防線。換成沒經驗的人，可能連下個月帳單為什麼多了十倍都不會知道。」而 Zeabur 主打的客群正是後面那種人。
技術上到底發生什麼事？先搞懂「環境變數」
任何上線的網路服務都要記住一些「只有它自己該知道」的事：連哪個資料庫、密碼是什麼、用哪組帳號呼叫外部服務。 這些設定值統稱環境變數，可以把它想成掛在服務門口的一串鑰匙，每把上面還貼了標籤，寫明是開哪一扇門的。
其中一類鑰匙特別值錢，就是 AI 服務的API Key。它是你向 OpenAI、Anthropic 這類服務下單的憑證，用多少算多少，帳單記在金鑰主人身上。換言之，這種鑰匙一旦外流，別人開始用，你的錢就開始被花掉。
Zeabur 確認外洩的環境變數名稱共 26 個，涵蓋 AI 服務金鑰（OPENAI_API_KEY、ANTHROPIC_API_KEY 等）、AWS 與 GitHub 等雲端和版控憑證、資料庫連線字串與密碼，以及 Stripe 金鑰與 JWT_SECRET 等，完整清單在官方事件頁上。
至於存在自訂名稱底下的憑證，官方的說法有明確條件：只有當內容符合 Zeabur 列出的 AWS、GitHub、Anthropic、OpenRouter、OpenAI 或 Stripe 等可辨識憑證格式時，才確認列入外洩範圍。改名字沒有用。
破口不在核心系統，在一個正要退役的叢集
依 Zeabur 在 8 月 30 日補上的說明，破口的起點是一組外洩的 AWS 高權限管理憑證。攻擊者用它進入 Zeabur 位於 AWS 東京機房的一個「共享叢集」（一組共同運作、彼此連通的伺服器），該叢集屬於邊緣服務、當時已在逐步停用階段；進入之後，攻擊者取得它原本用來連線核心系統資料庫的內部通道，最終連上主資料庫。
Zeabur 特別澄清的是：它的核心後端服務並不部署在 AWS，而是跑在另一家雲端服務商的獨立環境，並設有設備級的 VPN 存取限制。也就是說，被打進去的不是核心系統本身，而是核心系統的一條舊連線。官方表示，已取得的紀錄中沒有發現攻擊者取得可存取其他核心服務的憑證。
進到資料庫後，官方說紀錄顯示攻擊者對使用者的環境變數執行了「定向查詢與匯出」；至於客戶資料、服務與伺服器設定等類別，紀錄主要是計數、查看資料大小這類探查動作，沒有大規模讀取或匯出的直接證據。官方同時寫明：沒有直接證據，不等於能完全排除其他資料曾被存取。
要提醒的是，完整的第三方鑑識報告尚未發布，上述攻擊路徑與範圍來自 Zeabur 自行公布。
受影響用戶現在該做什麼？六個問題一次看
Q1：我怎麼知道自己有沒有受影響？
Zeabur 已逐一通知可能受影響的使用者，通知會列出相關專案、服務與輪替建議。沒收到通知也建議自查：曾在環境變數裡放過那 26 個名稱底下的憑證，或以自訂名稱存放、但內容符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI、Stripe 可辨識格式的金鑰，都應視為可能受影響。
Q2：處置順序該怎麼排？
- 立即到各服務商後台停用或撤銷可能外洩的 API Key、雲端憑證、資料庫密碼與 Stripe 金鑰，再建新憑證。
- 檢查用量、帳單與登入紀錄，保存截圖、時間、金額、來源 IP 等證據。
- 同時聯絡第三方服務商與 Zeabur，提出爭議用量與賠償申請。
- 若信用卡已出現未授權扣款，再聯絡發卡行。停卡不能取代撤銷 API Key，金鑰沒撤銷，盜用就不會停。
設定支出上限時也要注意，各服務商機制不同，不能一律當成硬性阻擋。OpenAI 的專案月度支出上限預設是軟性門檻，超過後請求仍會繼續處理，只依設定發出告警，除非另外開啟強制硬上限才會擋下請求；Anthropic 則是在使用者自訂的支出上限達到後停止 API 請求，要提高或移除上限才會恢復。動手前先確認自己用的服務規則。
Q3：只換那一把有問題的金鑰夠嗎？
不夠。Zeabur 已將確認外洩的憑證類型與輪替教學整理成憑證輪替指南。至於把所有曾放在該平台的憑證全面輪替，屬於較保守的安全作法，並不代表 Zeabur 已證實所有憑證都遭讀取，而是在事件範圍尚未釐清前把不確定性降到最低。
Q4：我部署的服務、資料庫與伺服器安全嗎？
Zeabur 表示依已蒐集的證據，沒有發現攻擊者大規模存取或匯出用戶服務內部資料，也沒有發現他讀取伺服器連線設定或實際登入，但都不能完全排除技術上的可能。若環境變數裡有可直接使用的資料庫憑證，而該資料庫可從公開網路連線，攻擊者有可能用自動化工具嘗試連線。管理伺服器的用戶另建議輪替 SSH 金鑰、檢視登入紀錄、限制來源 IP 並關閉密碼登入。
Q5：信用卡與 Stripe 金鑰各要注意什麼？
第一，Zeabur 表示沒有證據顯示訂閱付款用的完整卡號與卡片安全碼（CVC）遭存取，這些資料由 Stripe 保管，Zeabur 系統與人員都無法取得。第二，使用者自行存放在環境變數裡的 STRIPE_SECRET_KEY 名列官方已確認外洩的項目，相關用戶仍須立即撤銷該金鑰，並檢查 Stripe 後台的操作與付款紀錄。
Q6：賠償怎麼申請？網路上流傳的外洩情報可信嗎？
賠償透過 Zeabur 技術支援工單提交，需附上服務商的用量紀錄、發生時間、金額或 token 用量，以及來源 IP、設備資訊等可供核實與配合執法機關調查的證據。至於網路流傳的各種「洩漏情報」，官方明言部分內容與內部掌握的情況矛盾且疑似藉此行騙，一律以官方公告為準。
資料來源：Zeabur 官方事件頁、林沅霖 Threads 貼文（8 月 28 日）、林沅霖 Threads 貼文（8 月 30 日）、@lidien.fu Threads 貼文、《創業小聚》、Zeabur 憑證輪替指南、《動區動趨》、OpenAI 支出上限說明文件、Anthropic 速率與支出上限說明文件
本文初稿為AI編撰，整理．編輯/ 李先泰
