台灣開發者愛用的部署平台，兩個月被駭兩次後關站（下）：一把永不過期的 token，與關站後你該做的事

Zeabur 第二次被駭：一把 2024 年建立、從未過期的管理 token，讓攻擊者讀走 321 萬筆環境變數。下篇整理入侵經過、關站時程、退款理賠，以及工程師該帶走的 6 個教訓。

10 月 14 日早上 9 點 36 分（台北時間，下同），有人拿著 Zeabur 內部的 AWS 金鑰開始動作。四分鐘後，他用上了一組共享叢集的管理 token。

這組 token 建立於 2024 年 1 月 10 日（UTC 日期），沒有到期日；今年 1 月被以明文寫進一個私有設定 repo；它能操作的管理介面，就開在公網上。8 月事件後那一輪「全部輪替」，沒有輪到它。

接下來大約 36 個小時，沒有任何告警響起。最後是使用者回報，Zeabur 才開始調查。

（上篇講了 Zeabur 是什麼、第一次怎麼被打穿。這篇講第二次入侵、關站，以及我們能帶走什麼。）

一、兩條路，最後在內網會合

路徑 A：共享叢集。攻擊者用明文 AWS 金鑰和這把管理 token，從外部進入 9 個區域的共享叢集，讀取所有服務的設定與機密，再進到使用者資料庫服務的容器裡下讀取指令，最大宗是 n8n。
路徑 B：GCP 專用伺服器。Zeabur 代管的 GCP 伺服器，初始化設定裡存著明文 root 密碼，攻擊者手上又有一把讀得到設定的舊 GCP 金鑰，Zeabur 研判密碼就是這樣被拿到的。最後 101 台伺服器（92 位使用者）被以 root 登入，其中 50 台被加上攻擊者的 SSH 金鑰，另有 16 份客戶磁碟複本被掛到攻擊者開的 VM 上。這個 root 密碼問題 9/3（UTC 日期）就發現了，但事發前沒修好。
會合：10/15 23:30，攻擊者用路徑 A 拿到的內網管理憑證，從一台被攻陷的 GCP 伺服器把自己的節點加進 Zeabur 內網，再用一個內部「唯讀」資料庫帳號讀取平台資料庫：10/16 00:10 到 00:47，37 分鐘。

關鍵時間線：

10/14 09:36：第一次使用內部 AWS 金鑰；09:40 第一次使用管理 token
10/14 21:40：開始在使用者資料庫容器內下指令，同時開始 root 登入 GCP 伺服器
10/15 21:56：收到使用者回報，才開始調查
10/16 00:08：狀態頁第一次公告，當時只說共享叢集上的 PostgreSQL、MySQL 受影響
10/16 00:10–00:47：平台資料庫被讀取
10/16 04:48：狀態頁更正，影響比先前公告更大
10/16 05:05：目前紀錄中攻擊者最後的活動
10/17：宣布停止營運；10/19 發布初步報告

二、外洩規模

3,218,965 筆環境變數（名稱與值，已確認）
321,810 個帳號資料（email、使用者名稱、手機等，已確認）
865 個資料庫服務被下讀取指令（不是每個指令都成功，實際被拿走多少資料是官方的估計；其中 736 個是以 PostgreSQL 為後端的 n8n）
101 台 GCP 伺服器被 root 登入（已確認）

n8n 最值得警惕：Zeabur 檢查的 607 個以 PostgreSQL 為後端的 n8n 裡，有 602 個把加密金鑰設在環境變數。金鑰和被加密的資料放在同一個地方，攻擊者在容器裡一讀，n8n 裡存的第三方憑證就等於明文外洩。因為是在容器內讀取，8 月後改過資料庫密碼也擋不住。

另有幾項官方「無法確認」、一律當作已外洩處理：台北（tpe1）與香港（hkg1）的資料庫備份是否被下載；Hetzner 359 台、DigitalOcean 48 台伺服器的管理 token 外洩後是否被使用。Zeabur GitHub App 的私鑰也被讀走，10/15 23:05 到 10/16 02:54 之間持有它就能存取使用者授權的 repo，目前沒發現被使用。

三、攻擊者在找什麼？AI 的 key

Zeabur 從指令內容研判，攻擊者主要在找能直接用的 API key，特別是 AI 服務的：在平台資料庫裡搜尋 key、大量讀取 n8n 和 new-api／one-api（常用來轉發 AI API 的閘道）裡的憑證，還試著用 Zeabur 的 AWS 金鑰呼叫 Amazon Bedrock（全部失敗、沒有產生費用）。官方也提醒，這只是對意圖的觀察，帳號資料同樣被讀走了。

事後有一把使用者的 OpenAI key 在 10/16 早上被用來送出約 1,107 次影像請求。官方推測與這次外洩有關，但無法確認。

四、為什麼 8 月修過了，10 月還是被打穿？

這是整份報告最值得讀的部分。8 月事件中，Zeabur GitHub App 的私鑰被讀走，8/31（UTC 日期）換掉了；但私鑰「讀得到的東西」，也就是設定 repo 裡那堆明文憑證，沒有跟著換。

官方推測，攻擊者在私鑰被換掉前約 4 天的空窗期用它讀了設定 repo。但官方同時寫明這只是推測，不應當成事實引用，而且 8 月和 10 月的攻擊者 IP 沒有重疊。報告也記錄了幾件還查不清的事：設定 repo 在 8/30 和 9/2（UTC 日期）被人透過一名員工的 GitHub 授權下載；9 月初（9/1–9/5，UTC 日期）也有不明來源用 root 密碼登入 GCP 伺服器。

不管憑證最初怎麼漏的，結論都一樣：輪替的範圍，要從「這把外洩的 key 碰得到什麼」往外推，而不是只換你知道外洩的那一把。

其他讓傷害變大的因素：

備份裡存著全部機密，備份金鑰又和其他機密放在一起。最荒謬的一幕：事件處理中新換上的備份金鑰，被 10/16 00:00 的備份收了進去，攻擊者 04:30 就拿去用了。
一把只需要讀一個 bucket 的金鑰，實際上能讀所有 bucket。
「唯讀」資料庫帳號能讀全部資料：唯讀不等於安全。
一個四個月前就下線的服務，它的 deploy key 還能讀設定 repo。

也有一群人逃過一劫：8 月後照指引把環境變數搬到自己專用伺服器上的專案，這次不在平台資料庫被讀取的範圍內（前提是主機本身沒被入侵）。少集中保管一份機密，被偷時就少一份。

五、關站：時程、退款與理賠

10/17 宣布關站時，不少使用者是在 Threads 上刷到才知道，沒收到 email。隔天 Zeabur 官方帳號在 X 上回覆：「你说得对，停止运营这么重要的事，应该让每一位用户都第一时间收到通知，这一点我们没做好，抱歉。」

即日起：停止新購專用伺服器與網域，網域可自助轉出。
11/30 前：官方建議完成搬遷；資安理賠截止，退款開單也截止（之後退款改用 email 申請）。
12/1 起：停止續約，專用伺服器各自到期就關；共享叢集服務全部暫停（可手動恢復來備份）。
12/31：所有服務停止，服務資料刪除。

注意：透過 Zeabur 租的專用伺服器到期後會被刪除、磁碟不保留，可能比 12/31 更早。

退款和理賠要分開申請：

餘額退款：11/30 前透過 Zeabur Support 申請，之後改用 email。上限是實際付的現金，官方舉例：儲值 20、拿到 100 贈送額度、用了 40，只退 20。帳號要等所有服務都停止後才會結算，越早停就越早拿到退款；服務跑到 12 月底的帳號，官方預計 2027/1/10 前完成付款。
資安理賠：另開一張單，11/30 前送出。要附上受影響的帳號與服務、外洩的金鑰類型，以及事件期間的第三方帳單或用量紀錄。

六、搬家：官方叫你把指南丟給 AI

Zeabur 的遷移指南是寫給 Claude Code、Codex 這類 coding agent 讀的：把連結丟給 agent，它會盤點服務、推薦去處，每個會改動東西的步驟都先問你。就算不用 agent，這幾項也一定要有人接手：

映像檔存在 Zeabur 的 registry，關站後拉不到，服務重啟就起不來。
*.zeabur.app 網域會失效；HTTPS 憑證要自己處理。
.zeabur.internal 內網連線和跨服務注入的變數，要換成新環境的寫法、帶走實際的值。
每日資料庫備份會消失，要先匯出，再自己設定備份。

官方說最常見的失敗點是映像檔和注入的變數。還有一句提醒很重要：不要把 Zeabur 的 token 貼進 AI 對話，讓 agent 用你電腦上已登入的 CLI 就好。另外，Velox Data 的整理提醒：用 Zeabur 備份的 data.sql 還原後，資料庫密碼會變回舊的，還原完要再改一次。

七、工程師該帶走的 6 個教訓

外洩後的輪替，要算爆炸半徑：換掉外洩的 key 不夠，還要換它讀得到的所有東西。
不要有永不過期的管理憑證：設期限、定期輪替；管理介面不要開在公網。
機密不進 repo、不進備份：私有 repo 不是保險箱；備份金鑰要和其他機密分開。
加密金鑰不要和資料放一起：n8n 的例子說明，放在一起就等於沒加密。
為「合法憑證被濫用」設告警：兩次都是使用者回報才發現。要盯異常來源、異常時段、大量讀取。
每把 AI key 都要有上限、能單獨撤銷：一個專案或 agent 一把 key，設用量上限和帳單告警。

PaaS 的方便是用信任換來的。把 key 放進平台的環境變數頁，平台就成了你安全邊界的一部分。這不代表不能用 PaaS，而是要假設它有一天會被打穿，然後讓那一天的損失越小越好。

下篇重點

長效、明文、可從公網使用：三個條件湊齊，一把 token 就能打開整個平台。
攻擊者用的是合法憑證，傳統告警不會響。
11/30：資安理賠與退款開單截止；12/31：全部停止、資料刪除。
假設平台會被打穿，把每把 key 的爆炸半徑縮到最小。

Zeabur 的故事就講到這裡。諷刺的是，Zeabur 的遷移指南把 Railway 列為可以搬去的選項之一，而在 Zeabur 揭露入侵不到一週後，Railway 也在 10/21 揭露了自己的資安事件。Railway 表示，未經授權的第三方可能存取了加密的環境變數，其中一部分還取得了解密後的內容。大家有興趣的話，下一次我再來拆 Railway。

一天之中的時刻，由 Zeabur 公布的 UTC 時間換算成台北時間（UTC+8）。只有日期、沒有時刻的項目（2024/1/10、今年 1 月、8/30、8/31、9/2、9 月初、9/3），沿用 Zeabur 報告裡的 UTC 日期，換成台北時間可能差一天。文章與公告的日期，是官方網站上顯示的發布日期。

來源

Zeabur，〈Zeabur 2026 年十月資安事件（初步報告）〉，2026/10/19：https://zeabur.com/zh-TW/blogs/october-2026-security-incident
Zeabur 狀態頁：https://status.zeabur.com/incident/1091243
Zeabur，〈Zeabur 停止營運公告與服務遷移安排〉，2026/10/17：https://zeabur.com/zh-TW/blogs/zeabur-is-shutting-down
Zeabur，〈Service migration, refunds, and security incident claims〉，2026/10/22：https://zeabur.com/blogs/migration-refunds-and-security-claims
Zeabur，〈Migrating off Zeabur〉，2026/10/20：https://zeabur.com/blogs/migrate-from-zeabur
Zeabur 官方 X 回覆，2026/10/18：https://x.com/zeaburapp/status/2111688287664693440
iThome：https://www.ithome.com.tw/news/179804
BleepingComputer，2026/10/20：https://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/
Velox Data：https://velox-data.com/blog/zeabur-security-keys/
kurohsu.dev，〈PaaS 的方便，是用信任換來的〉：https://kurohsu.dev/notes/zeabur-incident-vibe-coding-security.html
Railway，〈Security Disclosure: Wednesday October 21st〉，2026/10/21：https://blog.railway.com/p/security-disclosure-wednesday-october-21st