一個使用者部署的聊天機器人，一路走到平台的主資料庫

發生了什麼

把 PaaS 想成一棟有管理員的公寓：你把鑰匙交給管理員保管，換來不必自己顧門。這份報告寫的是，有一戶房客自己裝的對講機有漏洞，有人從那裡進了大樓的公共管道間，在管道間撿到一張管理員的門禁卡，再用那張卡進了管理室，最後打開了放所有住戶備用鑰匙的保險櫃。

Zeabur 在 2026 年 9 月 9 日發布完整報告，同一天狀態頁標記事件結案。報告的第一手性質要先講清楚：這是平台自己寫的事後報告，所有時間都是 UTC，時間點是「最早確認的紀錄」，報告特別提醒，憑證第一次被使用的時間，不代表攻擊者就是那一刻拿到的。

1. 2026-08-27 02:34 UTC
   最早確認的異常 API 請求與探測
   官方完整報告
2. 02:36
   一位團隊管理員的 Legacy API Key 第一次被使用，查詢帳號與 AI Hub 資訊；02:37 建立第一把 AI Hub 存取金鑰
   官方完整報告
3. 03:53
   第一次讀取專案環境變數的名稱與值
   官方完整報告
4. 05:39 → 05:46
   讀到內部服務的環境變數（含 AWS 金鑰）並登入 AWS；接著讀到內部管理服務設定裡的特權 AWS 金鑰，以 root 使用者登入並開始列舉雲端資源
   官方完整報告
5. 06:08 → 07:26
   在東京共用叢集建立異常的一次性作業；一個服務帳戶被授予叢集管理員權限
   官方完整報告
6. 07:54
   資料庫中最早確認的入侵紀錄；11:52 起出現大量讀取專案環境變數
   官方完整報告
7. 08-28 02:34
   接獲第一則 API 金鑰被盜用的回報，才確認事件
   官方完整報告
8. 08-28 08:53 → 17:03
   發出第一次通知（報告承認範圍評估不正確）、第二次通知；AI Hub 預防性暫停
   官方完整報告、狀態頁
9. 08-29 → 09-07
   與 AWS 溝通、補償審查、提供調查結果給主管機關、輪替內部憑證、發布重大安全更新
   官方完整報告、狀態頁
10. 09-09
    完整報告發布，狀態頁結案
    狀態頁
11. 09-22
    AI Hub 確定停止服務，未使用的實付額度退回為平台點數
    AI Hub 停止服務公告

從最早的探測到平台知道，中間是整整 24 小時；這 24 小時裡，攻擊者做完了上面每一格。

怎麼發現

報告的原話是：只在 8 月 28 日 02:34 接到 API 金鑰被盜用的回報後，才確認這起事件；當時的監控與告警沒有辨識出這次未授權存取。換句話說，第一個發現的人不在平台裡，是某個使用者或上游供應商看到自己的金鑰被拿去用了。

這一點比任何技術細節都值得停下來想：AWS root 金鑰被使用、服務帳戶被授予叢集管理員、正式資料庫被大量讀取，這三件事每一件都是告警規則最常見的範例。報告後來補上的監控項目，正好就是特權變更、異常雲端用量、可疑資料庫查詢。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是自己該做什麼，可以直接往「如何避免」繼續閱讀。如果你想知道攻擊者是怎麼一道一道跨過邊界的，下面開始進入技術拆解。

整條鏈只有第一格是使用者的程式。其餘六格，每一格都是一個「平常應該不通、應該不存在、應該有人看到」的地方剛好通了、剛好存在、剛好沒人看到。

這次外洩了什麼

外洩分兩層：平台自己的憑證（用來一路往上爬的），以及使用者交給平台保管的憑證（最後被讀走的）。

最後一句建議是整份報告對使用者最重要的一句：不是「收到通知的才換」，是「曾經放在這裡、現在還有效的，全部換」。

證據等級

這篇幾乎所有事實都來自平台自己的報告與狀態頁。能證明的是「平台怎麼說」；平台沒說的部分，本站不補。

他們怎麼處理

確認之後的處理節奏，可以從狀態頁一路看下來。8 月 28 日當天撤銷被濫用的內部憑證、封鎖存取路徑、預防性暫停 AI Hub、發出兩次通知。接下來一週：與 AWS 溝通、審查補償申請、提供調查結果給主管機關、延長稽核與鑑識資料的保存、輪替所有內部憑證、更換共用叢集主機、把路由資料和使用者憑證分開。

中間有一段插曲：8 月 31 日的安全強化工作意外影響了 GitHub 整合、環境變數管理與寄信功能，狀態頁特別說明這不是新的入侵。9 月 3 日另有第三方安全稽核在進行。9 月 9 日完整報告發布，產品面的改變是把環境變數從平台的中央資料庫移到使用者自己的專屬主機（新服務預設，共用叢集上的服務不會自動切換）。

哪裡做對，哪裡做錯

做對的是報告本身的寫法：時間精確到秒、把「最早紀錄」和「實際取得時間」分開、主動承認第一次通知範圍錯誤、承認監控沒發現、把使用者程式的漏洞和平台自己的責任切開寫，並且直接建議所有仍有效的憑證都要換，不是只換通知裡列到的。這種坦白在平台事故報告裡不常見。

做錯的，報告自己列了八條，本站只想把它們排成一句話：每一道邊界都假設前一道會守住。共用叢集假設租戶不會亂連、快取假設沒人進得來所以放了憑證、API 金鑰假設不會外流所以沒設期限、內部服務假設不會被讀到所以留著 root 金鑰、監控假設異常會很明顯。報告也提到，出問題的共用叢集與 Legacy Key 正在退役中，隔離與存取控制還沒做完，這是最常見的一種破口：要淘汰的東西，最容易沒人管。

如何避免

當天就能做的，是平台使用者那一側：把所有曾經放在平台環境變數裡、現在還有效的憑證列成一張表（名稱、服務、建立日期、最後輪替日期），照報告的建議排進輪替。輪替時記得撤銷舊的，建立新金鑰不會讓舊金鑰失效。

一個月內，讓每一把金鑰都有範圍和預算上限：AI 供應商的金鑰設月用量上限與告警、雲端金鑰只給必要權限、資料庫帳號一個服務一組。能用短期憑證或從密碼管理器注入的，就不要以長期明文放在任何平台的環境變數裡。

這一季，如果你自己也在經營多租戶的服務，把報告的八條根因當成稽核清單：租戶間網路是否預設不通、快取和佇列裡有沒有憑證、API 金鑰有沒有範圍與到期日、root 或同等權限的長期金鑰是否存在、維護作業能不能碰到正式資料、特權變更和異常查詢有沒有告警，以及正在退役的系統有沒有人負責。

這篇提到的項目要花多少錢

公開資料沒有任何金額，下表把缺口列清楚，再列預防的成本。

損失那幾格全是缺口，但使用者這一側的預防加起來大約一個多人日，而且不管你用哪個平台都一樣該做。

你可以學到什麼

站在攻擊者的位置看：他不需要找平台本身的漏洞。他只需要一個使用者部署的、有已知漏洞的應用程式，以及平台內部一連串「應該不會被碰到」的假設。打下一個平台，等於一次拿到上千個使用者的保險櫃。

下面五步全部唯讀，只列不改。不管你用不用這個平台，第一步和第四步都值得做。