Zeabur 被駭完整解析：AWS 管理金鑰、AI Token 盜刷與 612GB 暗網資料是真是假？

更新時間：2026 年 8 月 30 日（台灣時間）。這篇的每一句話，我都盡量押在 Zeabur 事故公告、LiteLLM 官方報告、各家安全公告與雲端供應商文件上，再對照公開社群的討論。調查還沒結束，官方之後放出來的東西，很可能會推翻我現在寫的一部分——這點請你先記著。

先認識這家公司。Zeabur 是一個台灣團隊做的雲端部署平台，賣點很單純：把 AWS、GCP、伺服器規格、環境變數這些煩人的設定，壓成一個「一鍵部署」的按鈕；它還開了 AI Hub，讓你用一把金鑰就能呼叫好幾家的模型，底層接的是 LiteLLM、n8n 這類開源元件。創辦人林沅霖是 Z 世代，這個專案的起點，說起來就是他的大學畢業製作。這兩年它大概是台灣開發者圈聲量最高的新創之一，註冊用戶衝破十萬，裡頭很多是新手、是拿 AI 寫完程式想找地方第一次上線的人。募資也不難看：2025 年 9 月美國創投 500 Global 領投、進帳約兩百萬美元，更早之前還入選過 YC China。問題就藏在這份成功裡——當一個平台把這麼多雲端複雜度收進單一介面，又替海量使用者保管著各式各樣的 API 金鑰，那麼一次 Variables 外洩，就不會只是「一家公司被駭」，而是順著這些金鑰，一路燒進別人的雲、別人的服務。

2026 年 8 月底，Zeabur 證實：攻擊者拿到了公司內部的一把 AWS 管理憑證，進了東京的 AWS 共用叢集，再摸到控制平面的 VPN，最後連上主資料庫，把使用者存在 Variables 裡的 API Key 和其他憑證查了出來、匯了出去。緊接著，一堆人開始回報 OpenAI、Anthropic、OpenRouter 的帳單冒出莫名其妙的用量；同一時間，駭客論壇上有人掛牌賣「Zeabur 完整資料」，號稱包含各種平台級權限，還有壓縮後約 612GB 的客戶資料庫。

這確實是一場影響很大的事故。但話說回來，論壇上那個人講的每一句，現在都還不能當真。真正已經釘死、而且光是這樣就夠嚴重的事實只有一個：一把內部的 AWS administrative credential，沒有被關在單一 AWS 身分或單一叢集裡，而是一路越權跨到了控制平面網路、主資料庫，還有客戶交給平台保管的那些 Secrets。

60 秒摘要

• 官方已確認：攻擊者取得 Zeabur 的 AWS 管理憑證，依序進入東京 shared cluster、控制平面 VPN 與主資料庫，並針對使用者 Variables 查詢與匯出。官方公告在 Zeabur incident page 持續更新。
• 官方已確認：確認涉及的秘密種類涵蓋 AI API Key、AWS、GitHub、Cloudflare、Linode、DigitalOcean、Stripe、資料庫密碼、JWT、private key 等；自訂變數名稱但值符合已知格式者也可能被辨識。
• 官方已確認：Zeabur AI Hub 使用的 LiteLLM 出現可疑活動，但 Zeabur 尚未確認它和本案的因果關係。
• 未經證實：論壇帳號宣稱持有完整 source code、Postgres／MongoDB dump、多雲管理權限、Google Workspace session、Kubernetes admin、WireGuard，以及約 612GB 壓縮資料。公開頁面沒有足夠證據驗證真偽與規模。
• 技術推論：可能的初始入口至少有四類：LiteLLM 惡意 PyPI 版本、LiteLLM Proxy 漏洞或部署錯誤、開發者／管理者端點或瀏覽器 Session 失陷、CI/CD／原始碼／Secret Store 洩漏。現階段不能從「偷到很多種類的東西」直接選定其中一個。
• 使用者現在該做：把所有曾放進 Zeabur Variables 的秘密視為可能外洩，保存用量與帳單證據後立即撤銷舊憑證、建立最小權限新憑證、更新部署、重啟並驗證，再檢查至少 30 天的異常活動。收到新 Key 不代表舊 Key 已失效。

先把證據分級：什麼已知、什麼只是聲稱

在往下讀之前，我們得先把手上的東西分類。哪些是官方蓋章的，哪些只是有人在論壇上喊——這兩者混在一起談，討論就廢了。

分這個級，不是要替誰卸責。恰恰相反，它讓批評更有殺傷力：你根本不需要證明「612GB 完整資料庫」是真的——光是官方已經認了的那條攻擊路徑，blast radius 就大得嚇人；反過來，也別因為賣家那個論壇帳號看起來很不可靠，就自我安慰說其他資料一定都安全。

事件時間線：目前能還原到哪裡

• 2026 年 8 月 27 日前後：依 Zeabur 對外通知，平台開始處理未授權存取事件；官方尚未公布最初 credential 外洩與攻擊者首次進入的可靠時間。
• 8 月 28 日 07:11 UTC：事故頁建立，初版說法是 internal service credential 被用來取得 project environment variable records，並列出確認涉及的變數名稱與格式。
• 8 月 28 日 17:42 UTC：Zeabur 表示 AI Hub 使用的 LiteLLM 出現可疑活動，暫停 AI Hub，並調查兩者關係。
• 8 月 29 日 09:57：新註冊論壇帳號發布販售文，宣稱擁有多種 Zeabur 平台資料、管理憑證與壓縮後約 612GB 客戶資料庫。
• 8 月 29 日晚間 UTC：Zeabur 更新更具體的攻擊鏈：AWS administrative credential → 東京 AWS shared cluster → control-plane VPN → primary database → customer Variables。
• 8 月 30 日：第三方鑑識仍在進行，LiteLLM 是否為入口、其他資料的實際存取範圍、論壇聲稱真偽仍未有最終結論。

這條時間線最要命的缺口，不是哪天發公告，而是攻擊者的 dwell time——那把 AWS Key 到底最早什麼時候漏的、第一次被拿來用是什麼時候、幾點鐘進了叢集、幾點鐘摸到 VPN、又是從哪一刻開始翻 Variables。少了這一串時間戳，使用者連「該回頭撈多久的 Log」都算不出來，只能瞎猜。

官方已確認的攻擊鏈：一把 Key 為何走得這麼遠

AWS administrative credential → 東京 shared cluster → 控制平面 VPN → 主資料庫 → 客戶 Variables。這串箭頭，每一個都是一次需要單獨交代的越權，不是「憑證被偷」五個字能打發的。

不過話得說回來，路徑上有幾個節點，跟中間隔了幾道獨立的安全邊界，是兩回事。如果那個 AWS 身分本身就同時管得到叢集存取、VPN material、資料庫 credential、KMS 還有稽核資源，那圖上看起來跨了好幾個系統，實際上可能從頭到尾都被同一個 trust root 牽著走。判斷一套架構的縱深，不是去數箭頭，而是去確認：每一次跨域，是不是都得再過一關——一關是前一個身分拿不到、簽不出、也改不掉的授權。

第一段：AWS administrative credential 到底有多大

官方到現在都沒說，它是 IAM User Access Key、STS 臨時憑證、EC2／EKS 的 workload role，還是別種 machine identity；attached policies、permission boundary、SCP、能碰哪些帳號、能不能 AssumeRole、Session 多長、存在多久，一律沒公布。所以我也不能替他們腦補成「Zeabur 把一把永久的 AdministratorAccess Key 塞在某個服務裡」——那是猜的。

但從結果反推，這把 Key 的 effective permissions，至少足夠鋪出一條通往 shared cluster 的路。Zeabur 真正該攤開的，是權限展開後的樣子，而不是幾個 policy 名稱：它到底能碰哪些 account、EKS cluster、IAM role、Secret、KMS key、logging resource？攻擊者能不能靠它再簽發 Session、改信任政策、種一個新的持久化身分？而如果——這是最難堪的假設——這個身分連 CloudTrail 都停得掉、刪得掉，那整份事故報告的證明力，會直接再掉一截。

第二段：shared cluster 是 workload plane 還是 management plane

「東京 AWS shared cluster」這幾個字，在沒看到拓撲之前，別急著跟「承載客戶 workload 的多租戶共用叢集」畫上等號。官方沒提到 tenant escape，也沒說有 container breakout。如果它是跑客戶工作負載的叢集，那要問的是：為什麼在 workload plane 旁邊，會有一條摸得到 control-plane VPN material 的路？如果它是平台自己的內部管理叢集，那要問的就變成：為什麼這麼多高權限能力，全擠在同一個 failure domain 裡？

2026 年 2 月，Zeabur 宣布要逐步淘汰 Shared Cluster 的時候，說過它的 stability and security 已經被 “thoroughly proven”——原文還躺在 官方 changelog 裡。出了事，不見得就代表當初那句話是謊言。但「充分證明」這四個字，應該經得起追問：證明的到底是 tenant network isolation？是 container boundary？還是 shared cluster 跟 control plane 之間真的是兩個獨立安全域？如果它其實只是「一段時間內沒出過大事」，那 assurance 就跑到 evidence 前面去了。

第三段：從叢集摸到 VPN，可能根本不是另一道門

Zeabur 的 Security Practices 寫得清楚：production database 透過 Tailscale 存取，只有被核准的使用者和裝置能進內部系統。可官方事故頁到現在只寫了「VPN」，沒挑明它是不是文件裡那套 Tailscale。

假設它就是 Tailscale 好了，那也還得再分：攻擊者到底拿到的是什麼？是一把可重複使用、還預先核准過的 auth key？是既有的 node identity？是 OAuth session、tagged machine、subnet router，還是他乾脆接管了一台本來就被放行的裝置？Tailscale 的 device approval 文件 說得明白，新裝置通常要人工核准，但 pre-approved 的 auth key 是可以自動放行的；而 auth key 又能設成 reusable、ephemeral、expiring，還能掛 tag。所以「我們有裝置審批」這句話，並不能證明那個 machine identity 真的被另一道人為關卡擋下來過。

第四段：VPN 走得到，不該等於主資料庫隨便讀

VPN 解決的是「連不連得到」，它不該一併把 database authentication、跨租戶授權、解密權限都送給你。這中間，理應還站著 DB principal、collection/table scope、tenant predicate、query rate／bytes 上限、大量讀取的偵測，以及一份獨立的稽核。所以真正該問的是：攻擊者是用哪個 principal 登進去的？它讀得到哪些 database、哪些 collection、哪幾個租戶？一次能撈多少？那些 Variable，存的是 plaintext？是 application 加密過的 ciphertext？還是透過某個應用服務，正常解密之後再匯出去的？

MongoDB Atlas 用 AES-256 做 encryption at rest，這是對的控制，但它守的主要是 disk、snapshot 跟底層 storage。Atlas 安全文件 講得很白：對一個已經拿到正常查詢或解密路徑的身分來說，它照樣看得到資料。所以真正的問題，是 data、解密服務跟 KMS permission 是不是全落在同一個 blast radius 裡：誰能解、一次能解多少、每一次解密，有沒有留下一筆那把 AWS 管理權限碰不到、也毀不掉的紀錄？

駭客論壇的 612GB 與完整 DB：逐項怎麼看

論壇那篇貼文，把資料吹成「August 2026 complete dump」，然後開了一長串清單：source code、Postgres dump、MongoDB dump、AWS secret key、GCP Project Owner service account、Google Workspace 管理員的 cookie／帳密／OTP、`[email protected]` 的 GitHub PAT、Stripe API key、Kubernetes cluster admin、還能用的 WireGuard，以及壓縮後約 612GB 的客戶資料庫。相關販售貼文出現在某資料外洩論壇，原始截圖見下。

未經證實：公開頁面上，沒有足夠證據撐得起 612GB、完整 DB，或那一長串存取「現在還能用」的說法。發文的帳號 2026 年 8 月才註冊，發文沒幾篇、聲望掛零，一開始留的 Telegram 又聯絡不上——這些訊號，確實讓人很難相信它。但話說回來，「看起來不可信」也一樣證明不了內容就是假的。

真要匯出 612GB 的壓縮資料，通常會留下一堆痕跡：長時間的查詢、讀了多少 bytes、CPU/IO 飆高、跨區或對外的 egress、分段下載、目的端的儲存……問題是，「通常會留痕」跟「Zeabur 手上剛好有這些 Log」是兩碼子事。萬一那個攻擊身分連 logging 都改得動，或者事故發生前根本沒開 DB audit、沒開 VPC Flow、沒記 egress，那你就不能拿一句「現在找不到」，去替外洩規模畫一條可信的上限。

LiteLLM 是不是初始入口？必須拆成兩個問題

有人一口咬定，Zeabur AI Hub 用的那套 LiteLLM 就是破口。這方向不是空穴來風——2026 年 LiteLLM 一年內同時吃了供應鏈植入和 Proxy 重大漏洞兩記。但「LiteLLM 有問題」跟「Zeabur 就是從 LiteLLM 被打進去的」，中間還隔著一段沒人補上的證明。

假說一：3 月惡意 PyPI 版本竊走 AWS 憑證

LiteLLM 的 官方供應鏈事故報告 承認，2026 年 3 月 24 日那短短約 40 分鐘裡，PyPI 上的 `1.82.7` 跟 `1.82.8` 被塞了 credential stealer。後面那個版本更狠，把東西放進 `litellm_init.pth`，Python 一啟動就跑；而它要偷的，正好是環境變數、SSH keys、AWS／GCP／Azure credential、Kubernetes token 跟 database password。你把這份清單，跟論壇貼文吹的那些東西擺在一起看——重疊得有點多。

想把這條假說升格成本案根因，Zeabur 至少得攤出這些：AI Hub 或相關 CI runner，在 3 月 24 日那天，是不是用了沒鎖版本的 pip install？有沒有真的裝到 `1.82.7`／`1.82.8`？SBOM、build logs、container layers 還原不還原得回去？主機上找不找得到 `litellm_init.pth`？DNS／proxy／egress 有沒有連上 LiteLLM 官方點名的那些惡意網域？還有最關鍵的一問——那把 AWS 管理憑證，當時是不是就躺在同一個環境裡？

反過來，要洗清這條路，也有很明確的方向。LiteLLM 官方講過，鎖了相依版本的 official Proxy Docker image，不受那次 PyPI 事件波及。如果 Zeabur 能拿簽章、digest、build provenance 加上歷史 registry artifact，證明自己從頭到尾只跑安全映像，而且 credential 根本沒進過那個執行環境，這條假說就會軟掉一大半。但光說一句「我們現在已經升級了」是沒用的——要查的是三月當下，到底跑過什麼。

假說二：LiteLLM Proxy 漏洞或設定錯誤被利用

CVE-2026-42208／GHSA-r75f-5x8p-qvmc 是 LiteLLM Proxy 在 API key verification 上的一個重大 SQL Injection，受影響版本是 `>=1.81.16, <1.83.7`，`1.83.7` 才補起來。公告寫得很直接：沒登入的攻擊者，就能讀、甚至可能改動 Proxy database 和它管的那些 credential。而 LiteLLM 2026 年這一整年，認證繞過、SSTI、pass-the-hash、MCP command execution 的公告還一個接一個。

這條路一樣得攤 Zeabur 的實際版本、對外路由、WAF／Proxy／DB Log 跟 exploit 的時間線。更要命的一點是：就算 LiteLLM 的 DB 真的被讀了，那也只直接解釋了 AI Gateway 手上那些模型金鑰而已。你還得再證明——那個 DB 裡頭裝著 Zeabur 的 AWS 管理憑證，或者 LiteLLM 的執行身分讀得到那把憑證。少了這一步，你沒辦法從一個 Proxy 的 SQL Injection，一步就跳到東京 shared cluster、VPN 跟主資料庫。中間那段路，得有人走給你看。

目前判定：LiteLLM 是一條該優先鑑識的強假說，但它終究還是技術推論。Zeabur 官方到現在只認了「可疑活動」跟「關係還在查」；任何把它寫成已定案 root cause 的標題，都是搶在證據前面跑。

另一條假說：作者或管理者端點被入侵

社群裡還有一種懷疑：是創辦人、開發者或管理者的電腦先中鏢。理由也講得通——論壇聲稱同時握有 Google Workspace 的 admin active cookies、帳密、OTP、個人 GitHub PAT、source code、多雲 credential、Kubernetes 加 VPN。這種橫跨瀏覽器、SaaS、雲端、本機檔案的大雜燴，確實跟 infostealer、browser session theft、密碼管理器失陷，或一台高權限開發機被接管的樣子，對得起來。

可是「對得起來」不等於「就是它」。管理叢集、CI runner、共用的 Secret Store、事故處理時的暫存檔、備份——這些地方，一樣可能把這批資料集中在一起。甚至，論壇那個帳號手上的貨，大可以是不同時間、不同來源東拼西湊來的，再包裝成「一次端點全拿」的樣子唬人。

這也正是為什麼，「改個密碼」遠遠不夠。Google Workspace 的 官方管理文件 白紙黑字提醒：懷疑帳號失陷時，重設密碼之後，還得把 sign-in cookies 一起重設。而如果這真是一起端點事件，Zeabur 就得交代，第三方鑑識到底有沒有查到員工的裝置、瀏覽器 session、MDM／EDR、GitHub 跟 Workspace audit——而不是只翻了 AWS 就收工。

「目前沒有直接證據」到底有多少證明力：Evidence Coverage

Zeabur 說，目前沒找到其他敏感資料被大量讀取或匯出的直接證據。這句話，作為一句保留說法，其實合格。真正的麻煩在別處：讀者根本不知道，這個「沒找到」，是建立在多少「事故發生前就已經存在」的紀錄上頭。

AWS 的 CloudTrail integrity validation 能靠簽章 digest，幫你抓出檔案有沒有被動過手腳；organization trail 更能把 Log 丟到成員帳號預設碰不到的獨立位置。一份夠格的事故報告，應該端得出一張 coverage matrix：哪些 Log 事故前就開著、留了多久、哪些是事後才補開的、哪些結論撐得起一條可信的 upper bound、又有哪些地方因為紀錄不夠，只能老實承認「無法排除」。

所以最後的調查，一定要把兩件事分乾淨：一件是事故後還撈得到的紀錄，另一件是事故前就已經在那裡的證據。前者頂多描述「現在還活著的 telemetry」；後者，唯有它同時具備完整 coverage、夠長的 retention、改不掉的不可竄改性，加上對得上的 egress 紀錄，才有資格替「最多外洩到哪」畫下一條可信的上限。少了其中任何一項，該說的就是「無法排除」，而不是把「不知道」包裝成「沒發生」。

這裡有兩個坑，要一起繞開：沒有證據，不代表 612GB 匯出這件事一定發生過；但同樣地，沒有證據，也絕不會自動證明它沒發生。一句話的證明力有多重，得看可觀測範圍、完整性、保存期限，還有攻擊者到底動不動得了那些證據。

Encryption at Rest 與 Stripe 說法，回答的是不同問題

AES-256 不等於可用 Secrets 不會被讀

環境變數這東西，只要應用啟動時得拿它來用，平台最後就一定得留一條「摸得到明文」的正常路徑。所以攻擊者可能直接讀到 plaintext；也可能先拿到 application-encrypted 的 ciphertext，再摸到解密服務；甚至，他只是去呼叫一個本來就設計來正常匯出秘密的內部 API。沒看到 schema 跟解密設計之前，我不會武斷說 Zeabur 把所有 Secrets 明文塞在 MongoDB 裡；但你也不能拿 storage encryption 這個答案，去回答一個「已授權的查詢／解密路徑被濫用」的問題——那根本是牛頭不對馬嘴。

卡號在 Stripe，不等於 Stripe Secret Key 沒風險

完整卡號跟 CVC 是 Stripe 在保管，這點澄清很重要。但使用者自己塞進 Variables 裡的那把 Stripe Secret Key，是另一個完全不同的風險面。Stripe 的 官方文件 講得清楚：一把普通的 secret key，預設就能代表整個帳戶發出範圍很廣的 API 請求；要縮小 blast radius，得靠 restricted key、IP restriction 跟 rotation。而 Webhook signing secret 又是另一把獨立的秘密，得分開輪換。所以，別把「卡號沒存在 Zeabur」這句話，偷偷讀成「Stripe 整合沒有風險」。

受影響使用者：P0、24 小時、7 天處置清單

先講一個心態：不管你有沒有收到個別通知，只要你曾經把一把還能用的 credential 丟進 Zeabur Variables，就該用「它可能已經外洩」的前提來盤點。官方說會依變數名稱跟已知格式發通知，但自訂格式、舊值、早就刪掉的環境、那些格式辨識抓不到的秘密——很可能根本不在同一套通知邏輯裡。所以，「我沒收到信」從來就不是一張安全證明。

P0：現在就做

1. 保存證據：截取通知、key 名稱與建立時間、provider usage/cost、帳單、自動加值、request ID、來源 IP、登入與部署紀錄。濫用仍在進行時，以立即撤銷為優先，不要為了多留一張截圖繼續承擔費用。
2. 列出所有秘密：跨 project、service、environment 盤點現存、改名、刪除與歷史 Variables；包含手動貼入的 JSON service account、private key、連線字串與 webhook secret。
3. 撤銷高影響憑證：AI provider、AWS／Google Cloud、GitHub PAT、Cloudflare、Linode／DigitalOcean、Stripe Secret Key。不要只建立新 Key；確認舊 Key 已 disable、delete、expire 或 revoke。
4. 限制損失：暫停不必要的 provider 自動加值，提高異常通知敏感度，將新 Key 設定 spend cap、expiration、IP restriction、workspace／project scope 與最小權限。
5. 建立事件單：同時向 provider 與 Zeabur 送出時間、金額、key identifier、request ID 與處置證據，保存工單編號。

24 小時內：按憑證種類處理，不能一套流程通吃

正確的輪換順序

一般的服務，可以照這個順序走：先建一把最小權限的新憑證 → 更新 secret store／Variables → 重新部署或 reload → 確認新憑證的流量沒問題 → 再撤掉舊憑證 → 最後回頭查舊 Key 的歷史使用。但要是舊 Key 這會兒正在被人盜用，那就別講究順序了——先撤，認了那段短暫中斷，再把服務救回來。兩把 Key 並存，是為了零停機才設計的權宜之計，不是拿來無限期地替攻擊者開著門。

7 天內：完成擴大調查與架構修補

• 調查至少回看 30 天；若 LiteLLM 供應鏈假說、Key 建立時間或 provider last-used 指向更早，擴大到 2026 年 3 月 24 日或憑證建立日。
• 把一把全域 Key 拆成每環境、每服務、每專案 Key，設預算、到期、IP、model/resource allowlist 與告警。
• 從 Zeabur 以外建立獨立的 usage/cost、登入、DNS、雲端 audit 與 egress 監控，避免平台與證據同時失陷。
• 掃描 Git history、CI artifacts、container layers、備份、支援工單與開發機是否仍殘留舊 secret。
• 記錄實際工時、停機、第三方調查、客戶通知與合規成本；這些未必都在 Zeabur 現行直接盜刷賠償範圍內，但需要保留證明。

Zeabur 必須回答的 30 個技術問題

1. 被偷 AWS credential 的類型、Key ID 類別、建立時間、最早／最後使用時間與 Session Duration？
2. 它掛哪些 managed/inline policy、permission boundary、SCP，實際 effective permissions 是什麼？
3. 可操作哪些 AWS account、region、EKS cluster、IAM role、KMS key、Secret 與 logging resource？
4. 能否 AssumeRole、修改 trust policy、建立 user/key 或簽發後續 Session？
5. credential 原本存放在哪裡，為何存在於該環境，為何不是短效 workload identity？
6. 初始外洩時間與方法是否已確定？第三方鑑識如何驗證？
7. 東京 shared cluster 是 customer workload plane 或 internal management plane？
8. 各平面分屬哪些 account、VPC、subnet、security group 與 trust domain？
9. 攻擊者如何進 EKS：AWS API、access entry、aws-auth、kubeconfig 或既有節點？
10. 取得的 Kubernetes RBAC 是 namespace scope 還是 cluster-admin？
11. 可否 list/watch/get Secrets？相關 K8s audit 是否事故前已開？
12. 所謂 VPN 是否為文件中的 Tailscale？
13. 被取得的是 reusable/pre-approved auth key、node identity、OAuth session、subnet router 或既有裝置？
14. 新增裝置、tag、route、ACL 變更與 flow 是否有完整紀錄？保存多久？
15. VPN 可達後還需要哪個 DB principal，如何取得？
16. 該 principal 能讀哪些 database、collection/table、tenant 與欄位？
17. 是否強制 tenant predicate、query rate、records/bytes 上限與 bulk-export 告警？
18. Variables 在 DB 中是 plaintext、ciphertext 或 reference？
19. 誰能呼叫解密路徑？KMS、data 與 decrypt service 是否同一 blast radius？
20. 每次 secret read/decrypt/export 是否有不可由該 AWS 身分修改的 audit？
21. 事故前已啟用哪些 CloudTrail、EKS、VPN、MongoDB、VPC Flow、egress、application export logs？
22. 各 Log 的 coverage、filter、retention、integrity 與 Blind Spot？
23. 攻擊者身分能否停止、修改或刪除這些紀錄？
24. 實際被查詢與匯出的 users、projects、variables、regions、records、bytes 各是多少？
25. 對「其他資料無大量匯出直接證據」能建立多可信的 upper bound？
26. LiteLLM 的版本、安裝來源、SBOM、映像 digest、3 月 build logs 與惡意版本 IOC 結果？
27. LiteLLM CVE 路由是否公開可達，WAF／Proxy／DB 是否看到利用軌跡？
28. 端點鑑識是否涵蓋開發者／管理者電腦、瀏覽器 Session、EDR、Google Workspace 與 GitHub audit？
29. 第三方鑑識公司是誰、scope 是什麼、如何驗證 remediation 已有效？
30. 最重要的：同一把 credential 明天再外洩，新的架構最多讓它走到哪裡，哪個獨立控制會讓故事停下？

平台級修復：不能只做全面輪換與加強監控

• 消除長期雲端管理 Key：改用 OIDC／STS／workload identity，短效 Session、細分 role、限制可 AssumeRole 路徑與 resource。
• 分離失敗域：workload plane、management plane、primary database、KMS／decrypt service、security logging account 分帳號與網路域，避免一組 automation identity 橫跨。
• VPN 不是萬能邊界：裝置註冊、route、subnet router 與 DB authentication 分離；高權限 machine identity 採短效、不可重複、需獨立審批與異常告警。
• Secrets 按租戶／分域保護：envelope encryption、獨立解密授權、per-tenant／per-service key、JIT access、雙人審批、rate/bytes limit 與大量讀取中止機制。
• 獨立且不可竄改的稽核：organization-wide CloudTrail、EKS audit、VPN config/flow、DB access/audit、KMS decrypt 與 egress logs 寫入獨立 security account，搭配 object lock／integrity validation。
• 縮小 egress：管理叢集與 DB 不應可任意外連；對大量外傳、異常目的地、長時間壓縮／讀取與跨區流量告警。
• Secret access 偵測：對高價值 credential 放 honeytoken／canary、偵測 pattern enumeration、跨 tenant sequence、異常 batch、非典型 client 與短時間大量解密。
• 供應鏈可追溯：固定 dependency、SBOM、簽章映像、可重現建置、隔離 build runner，保存足以回溯 3 月事件的 provenance。
• 端點與 SaaS：管理員採 phishing-resistant MFA、受管裝置、EDR/MDM、Session 控制、PAT 與 OAuth app 盤點；改密碼時同步撤 Session。

Kubernetes 官方也提醒過一件容易被忽略的事：Secret 預設未必在 etcd 裡加密，你得自己去開 encryption at rest、上最小權限、再 audit list/watch/get，細節可參考 Kubernetes Secrets good practices。但講到底，就算你每一層都加了密，只要同一個高權限身分，手上同時握著資料和解密路徑，那這套架構，也不過是把鎖跟鑰匙，一起擺進了同一個房間罷了。

賠償、通知與第三方鑑識：還缺什麼

Zeabur 願意核實、並支付 credential 盜用衍生的額外費用，這是必要的，也值得肯定。但使用者的成本，從來不只是那張雲端帳單。還有 Secret inventory、輪換、重新部署、停機、翻 Log、第三方鑑識、通知自己的客戶、法遵評估，以及最難量化的那一塊——信任的損耗。我現在不會說 Zeabur 拒賠這些項目，因為官方根本還沒把話講完；但反過來，你也別預設現在那張表單，已經把這些全涵蓋進去了。

通知機制這一塊，同樣得攤在陽光下：誰是因為 key name 命中的、誰是因為 value pattern 命中的、查詢的 window 抓了多長、刪除的或歷史版本的 Variables 算不算數、通知會不會隨著鑑識進度更新？如果平台只通知「已經被查詢過」的 Variables，那使用者還是得弄清楚——這個「沒被通知」，到底是沒命中、是沒 Log、是已經排除，還是根本還沒查到那裡？這四種，差得可遠了。

FAQ

沒有收到 Zeabur 通知，就代表安全嗎？

不代表。通知可以是一條重要證據，但它會被查詢紀錄、命名與格式辨識、歷史資料、還有調查進度給影響。只要你曾經把高價值的 secret 丟進 Variables，就該乖乖盤點，並且用風險的角度去輪換。

612GB 完整客戶資料庫是真的嗎？

截至本文更新，未經證實。Zeabur 認了主資料庫跟 Variables 被存取，但官方紀錄目前撐不起論壇宣稱的那個完整資料集和 612GB 的規模。要坐實它，得拿得出 manifest、時間、records/bytes、query 跟 egress 這些驗得了的證據——缺一不可。

LiteLLM 已被證實是入口嗎？

沒有。LiteLLM 的惡意 PyPI 版本、那個重大 Proxy 漏洞，都是貨真價實的一手技術事實，Zeabur 也承認 AI Hub 有可疑活動；可是版本、IOC、部署跟因果時間線，官方一個都還沒公布。它是強假說，不是定案的 root cause。

是創辦人或作者電腦被駭嗎？

目前沒有公開證據能定案。論壇聲稱的那堆跨 SaaS、多雲資料，跟端點 infostealer 對得上，但一樣能用管理叢集、CI runner 或 Secret Store 集中來解釋。要下判斷，得看 EDR、瀏覽器 Session、SaaS login 跟 credential placement 的時間線，而不是盯著「他偷了哪些種類的東西」去倒推根因。

只換 OpenAI API Key 夠嗎？

不夠。你得盤點所有曾經存放的 AI、cloud、GitHub、DNS/CDN、Stripe、database、JWT、OAuth、SSH、TLS 跟 webhook Secrets；更新依賴、重新部署、撤掉舊憑證，再回頭查使用紀錄和持久化。

資料庫有 AES-256，為何 API Key 還能被讀？

At-rest encryption 守的，主要是 storage、snapshot 被人整個搬走的情況。可你的應用要用那把 API Key，就一定得有一條「正常查詢或解密」的路；攻擊者一旦拿到這條授權路徑，加密磁碟本身，是攔不住他的。

波波觀點：真正的問題，是攻擊為何沒有更早停止

這起事件，真正該被追問的，不是第一把憑證怎麼漏的——而是攻擊者憑什麼能從一個 AWS 身分，一路跨進 shared cluster、控制平面 VPN、主資料庫，最後摸到客戶的 Secrets。當一個平台把 deployment、database、domain、Secrets 全塞進同一個乾淨漂亮的介面，它其實是替使用者默默扛下了背後那一整套看不見的 IAM、VPN、KMS、DB role、audit log 跟 failure domain。介面愈簡單，這份責任就愈重：你得拿得出可驗證的隔離、最小權限跟稽核證據，去證明那些被你藏起來的複雜度，真的有被管好——而不是只是被藏好。

哪家公司不會被入侵呢？成熟度的差距，從來不在「有沒有被打」，而在攻擊者踩到第一個立足點之後，還能往前走多遠、平台自己看得見多少、能不能替影響畫出一條可靠的上限，以及——同樣的起點下次再冒出來，故事會在哪裡停住。退一萬步說，就算最後查出來 Zeabur 是 LiteLLM 供應鏈攻擊的下游受害者，你也躲不掉那個問題：為什麼一個第三方元件所在的環境，碰得到 AWS 的管理憑證？就算最後查出來是管理者端點失陷，phishing-resistant MFA、Session 控制、最小權限、管理平面分離——這幾關，一關都少不了。

一份好的 Postmortem，重點從來不是「我們已經輪換了幾把 Key、補上了幾條監控」。它該端出一個可以重現的反事實測試：讓一把同等權限的 AWS credential，在隔離環境裡再漏一次，然後證明給大家看——它拿不到 VPN material、沒辦法跨租戶查詢、大量解密不了 Secrets，也動不了調查的紀錄。唯有能證明「相同的起點再來一遍，攻擊會被哪一個獨立控制擋下來」，所謂的修復，才總算從一句承諾，變成一個驗得了的結果。

參考來源

• Zeabur：Unauthorized Access to Project Environment Variable Data
• Zeabur Security Practices
• Zeabur：Phasing Out Shared Cluster
• LiteLLM：Security Update — March 2026 Supply Chain Incident
• BerriAI/LiteLLM：compromised PyPI package timeline
• GitHub Advisory：CVE-2026-42208 LiteLLM SQL Injection
• AWS CloudTrail trails and organization trails
• AWS CloudTrail log integrity validation
• Tailscale Device Approval
• Tailscale Auth Keys
• MongoDB Atlas Logging
• MongoDB Atlas Auditing
• Kubernetes Secrets Good Practices
• GitHub：Reviewing and revoking PATs
• Google Cloud：Service account key rotation
• Stripe API keys
• Cloudflare：Roll tokens
• yuhaooo0x：一把 AWS 管理金鑰，為什麼能一路走到主資料庫？
• 動區 BlockTempo：Zeabur 環境變數外洩事件與公司背景報導

本文會隨 Zeabur 最終 Timeline、Root Cause、Impact Scope、Remediation 與第三方鑑識結果更新。如果你已經中招被盜刷，先別急著發文——優先撤銷 credential、保存好 provider 那邊的證據、開一張正式工單，而且千萬別在公開留言裡貼出任何 Key、private key、cookie 或完整的連線字串。