Zeabur 第二次資安事件與停止營運拆解：攻擊怎麼發生、為什麼收掉、用戶現在該做什麼

10 月 17 日早上，Zeabur 創辦人林沅霖寄出一封信，開頭第一句就是：「我們將逐步結束 Zeabur 平台營運。」距離 10 月 14 日晚上的第二次資安事件，只隔了三天；距離八月底那一次，不到八週。

我們公司自己有數十個專案跑在 Zeabur 專用伺服器上，這兩封信（10/15 的資安通知、10/17 的停運公告）我們都收到了，現在正在排搬遷時程。所以這篇是用「同樣要搬家的用戶」的角度寫的：先把官方到底說了什麼整理清楚，再講你今天該做哪幾件事、照什麼順序做。

先講結論：12 月 1 日起服務就會陸續停，12 月 31 日是全部停止的日期，真正能用的時間比你以為的短。資安止血和搬家是兩件要同時跑的事，止血不能等搬完再做。如果你要找的是八月那次事件的金鑰止血細節，請看我們先前寫的 Zeabur 資安事件白話拆解；要直接看搬去哪裡、怎麼搬，請看姊妹篇 Zeabur 停止營運搬遷指南與替代方案。這篇專講第二次事件本身與停運的來龍去脈。

Zeabur 停止營運懶人包：三個日期決定你還剩多少時間

一句話：從今天起不能再買新的專用伺服器與網域，12 月 1 日開始服務陸續關閉，12 月 31 日全部停止。下面這張表把停運公告裡的時程、對你的影響、你該做的事放在一起，三十秒看完。

表格最右邊那欄的關鍵字是「現在」。停運公告寫得很清楚，12 月 31 日是全部停止日期，個別服務可能更早停；資料刪除日期、最晚匯出期限、Support 停止日都還沒確定。對要搬家的團隊來說，這代表時程表的底線是浮動的，越晚開始，風險越高。

官方也說正在準備遷移指南，還會提供給 Claude Code、Codex 這類 Coding Agent 讀的 Markdown 指南與 Skills。這對用 AI 寫程式、用 AI 部署的用戶是好消息，但在指南出來之前，你能先做的事已經很多：列專案清單、匯出資料庫、把環境變數抄出來（抄出來之後要換掉，下面會講為什麼）。搬去哪裡的比較，我們整理在 搬遷指南與替代方案。

從八月到十月：Zeabur 兩次資安事件與停運的時間軸

先看全貌：共享叢集在今年 2 月就宣布退場，八月和十月兩次事件都從共享叢集開始，第二次事件後三天宣布停運。把這幾個時間點串起來，才看得懂為什麼走到這一步。

下面這張表把每個時間點的官方原始出處列出來，方便你自己回頭查。台灣時間與世界協調時間（UTC）差 8 小時，官方英文公告多用 UTC，中文通知信用台灣時間，看到時間對不上時先換算一次。

每一列的原文都可以查得到：共享叢集退場公告、八月事件完整報告、AI Hub 停止服務公告、十月事件的狀態頁。停運公告目前還沒有放上官網部落格，社群上有用戶把整封信轉貼出來，內容與我們收到的信一致。

第二次 Zeabur 資安事件怎麼發生的：拿到平台管理憑證，等於拿到每個容器的後門

白話講：攻擊者這次拿到的是「管理整個共享叢集的鑰匙」，用它直接走進使用者的容器裡下指令，把資料庫內容和環境變數讀出來。這跟八月那次「繞一大圈去讀中央資料庫」的路線差很多，下一段會比較。

10/15 的通知信寫了四件事：攻擊者取得共享叢集的平台管理憑證；用它進入共享叢集上的使用者容器執行指令；讀取了部分使用者的資料庫內容與服務環境變數；主要目標是 n8n、PostgreSQL、MySQL、Redis 等資料庫與 AI 相關服務。官方在 10/15 撤銷了外洩的憑證、限制共享叢集的管理存取來源，之後沒有再觀察到攻擊者活動。

用大樓來比喻：八月那次，小偷是從一間房客的窗戶爬進來，一路摸到管理室翻檔案櫃；這次小偷手上直接拿著管理員的萬用鑰匙，挨家挨戶開門進去，打開你的抽屜看。管理憑證就是那把萬用鑰匙，容器就是每個房客的房間，你的資料庫與環境變數就在抽屜裡。

為什麼目標特別點名 n8n、資料庫與 AI 服務？這幾類服務有一個共同點：裡面放的東西可以直接換成錢或換成下一步的入口。n8n 存著串接各家服務的 credentials，資料庫裡有客戶資料，AI 服務的金鑰拿去就能刷用量。從變現的角度看，這是投報率最高的幾個抽屜。

有幾件事官方還沒說清楚，我們也不猜：管理憑證是怎麼外洩的、跟八月是不是同一條路徑的延伸、總共影響多少用戶。停運公告說完整報告會後續公布。這篇只寫官方信件與狀態頁上已經寫明的事，攻擊細節等報告出來再補。

通知信和狀態頁說法不同：專用伺服器到底有沒有事

這是這次最需要注意的落差。10/15 的通知信寫「目前確認的影響範圍僅限於共享叢集，尚未在專用伺服器上發現相關異常」，但官方狀態頁在台灣時間 10/16 凌晨 4:48 的更新寫了更正：調查發現事件比最初回報的範圍更廣，部分架在 Google Cloud 上的專用伺服器也遭到未授權存取，攻擊者握有平台資料庫的讀取權，外洩資料包含服務環境變數、帳號資訊、API Token 與 zSend 的 API 金鑰。

動區的報導也注意到同一個落差。停運公告則用「內部系統及部分客戶服務遭外部人士入侵」來描述，並說影響範圍比八月更大。三份文件放在一起看，比較穩的判斷是：就算你只用專用伺服器，也照共享叢集的標準做止血。狀態頁同時要求 Google Cloud 專用伺服器的用戶更改 root 密碼，並刪除不認得的 SSH 金鑰，特別是名稱標成 zeabur-pentest 的那一把。

為什麼共享叢集是資安事件的放大器

先講結論：共享叢集把很多用戶的容器放在同一套 Kubernetes 上，由同一組平台憑證管理。只要那組憑證外洩，整個叢集上的所有用戶會一起受害。這是共享架構的天性，跟哪家平台無關。

Kubernetes 你可以想成一個超大型的貨櫃碼頭調度系統，每個容器是一個貨櫃，調度系統負責把貨櫃放到哪台機器、什麼時候開、什麼時候關（想看基礎概念可以讀 Kubernetes 是什麼）。共享叢集就是很多家公司的貨櫃放在同一個碼頭，碼頭管理員有權打開任何一個貨櫃。平常這很有效率，價格也便宜；出事的時候，一張管理員識別證就能開所有櫃子。

還有一個比較少人注意的放大因素：退場中的系統最容易被冷落。八月事件報告自己就寫了，共享叢集與 Legacy API Key「雖已進入退場階段，我們仍應確保它們在停止運作前具備足夠的隔離與存取限制」。團隊把資源放在新產品上，舊架構只求不倒，這是所有軟體公司都會遇到的拉扯，也剛好是攻擊者最喜歡的縫。

這對自己養系統的公司也是一面鏡子。你公司裡有沒有「已經說要淘汰、但還在跑」的舊系統？舊的 FTP、舊的測試機、離職工程師架的那台小主機。它們最可能變成下一個入口，因為大家都默認它很快就會關掉，所以沒人去補。

Zeabur 第二次資安事件跟八月那次差在哪

差別有三個：入口不同、碰到的資料不同、影響的範圍變大。八月是從一個用戶服務的漏洞一路升級權限去讀中央資料庫；十月是直接拿到叢集管理憑證，進到用戶容器裡面讀資料庫本身。

最值得注意的是第三列。八月被讀走的是「鑰匙」（環境變數），換掉鑰匙就能止血；十月有一部分被讀走的是「抽屜裡的東西」（資料庫內容）。鑰匙可以換，已經被看過的資料收不回來。如果你的資料庫裡有客戶個資，除了換密碼，還要評估個資外洩的通報與告知義務。

第二個要注意的是九月那次安全升級的適用範圍。官方報告寫明，「環境變數改存放於使用者的伺服器」這個新做法只適用於專用伺服器，共享叢集上的服務不會自動切換。也就是說，八月之後沒搬離共享叢集的服務，十月時環境變數的保存方式跟八月一樣。這不是要怪罪用戶，官方二月時承諾過既有服務會繼續安全運行；只是從結果看，留在退場中的架構，風險比多數人估的高。

Zeabur 用戶止血清單：資料庫密碼要先在資料庫裡改

照這個順序做：先撤銷外部金鑰，再改資料庫密碼，再換應用程式自己的秘密，最後關公網、查用量。順序的道理是「先切斷攻擊者手上那些在別處也能用的東西」，AI 金鑰和雲端金鑰拿到哪裡都能用，資料庫密碼至少還要連得到你的資料庫才有用。

改資料庫密碼：先在資料庫裡改，再改變數

這是通知信特別強調、也最多人會做錯的一步。Zeabur 介面上的 PASSWORD 變數只是「告訴應用程式要用什麼密碼去連」，資料庫本身的密碼存在資料庫裡面。你只改變數，資料庫的實際密碼沒有變，攻擊者手上的舊密碼照樣能登入；而你的應用程式反而會因為密碼對不上而連不進去。

正確順序是：先連進資料庫執行改密碼指令，再把 Zeabur 上的變數改成新密碼，最後重啟所有連這個資料庫的服務。下面是三種常見資料庫的指令，使用者名稱請換成你自己的：

-- PostgreSQL
ALTER USER <使用者名稱> WITH PASSWORD '<新的長隨機密碼>';

-- MySQL
ALTER USER '<使用者名稱>'@'%' IDENTIFIED BY '<新的長隨機密碼>';
FLUSH PRIVILEGES;

# Redis（設定密碼後，記得同步改啟動參數或設定檔，否則重啟會回到舊值）
redis-cli -a '<舊密碼>' CONFIG SET requirepass '<新的長隨機密碼>'

改完之後有一個常被漏掉的地方：別的服務裡的連線字串。很多專案會把完整的 DATABASE_URL 或 REDIS_URL 寫在後端服務的變數裡，密碼就嵌在網址中間。資料庫密碼換了，每一個引用它的服務都要一起改、一起重啟。建議先把所有服務的變數名稱列成一張表，再一個一個勾。

n8n 用戶：換 N8N_ENCRYPTION_KEY 之前先想清楚順序

n8n 會用一把加密金鑰把 credentials 加密後存進資料庫，官方文件寫得很清楚，這把金鑰可以用 N8N_ENCRYPTION_KEY 環境變數指定。這次事件的麻煩在於，加密金鑰（在環境變數）和加密後的 credentials（在資料庫）都可能被讀走，兩個湊在一起就等於明文。所以只換加密金鑰不夠，每一組 credentials 背後的真實密碼也要到各服務商那邊換掉。

實際操作上，直接改 N8N_ENCRYPTION_KEY 會讓舊的 credentials 全部解不開。比較穩的做法是：先用 n8n 的 CLI 匯出工作流程備份，再把 credentials 清單列出來（知道有哪些要換就好）；接著到各服務商撤銷舊的、產生新的；然後在設好新加密金鑰的 n8n 上，用新的密碼重新建立 credentials，再匯入工作流程。如果反正要搬家，這一步可以跟搬遷一起做，在新環境用新金鑰、新 credentials 起一套乾淨的 n8n。

# 匯出所有工作流程（不含 credentials 的密碼）
n8n export:workflow --all --output=backups/workflows.json

# 匯出 credentials 清單用來盤點（加 --decrypted 會是明文，用完立刻刪除，不要上傳任何地方）
n8n export:credentials --all --output=backups/credentials.json

如果你的系統是外包團隊維護、金鑰都在廠商手上，這張清單你自己做不了，請直接把這一段轉給廠商，請他回報每一項的完成時間。八月事件那篇有一份外包廠商七問，可以一起帶去問。

Zeabur 退款、資安賠償與網域轉出：兩張單要分開開

最重要的一句：帳戶餘額退款和資安損失賠償是兩種不同的申請，都由 Zeabur Support 受理，送單時要註明是哪一項。混在一起寫，很可能只被處理其中一件。

賠償資料怎麼準備，可以參考八月那次的做法。八月事件的狀態頁要求申請 AI 金鑰盜刷賠償時，附上服務商後台的截圖，最好有每日與每把金鑰的用量，清楚標出異常時段與費用。這次雖然還沒公布具體規則，照這個標準準備最保險。另外，送單時只提供遮蔽過的金鑰識別資訊，不要把仍然有效的完整金鑰或密碼貼進工單。

網域建議排在最前面處理。網域是你所有服務的門牌，轉出需要時間（通常要等授權碼、等註冊商確認），而且跟搬主機可以分開做：先把網域轉到自己的註冊商，DNS 暫時還指向 Zeabur 上的服務，等新環境準備好再切換。這樣就算 Zeabur 比預期更早關，至少門牌還在你手上。

Zeabur 為什麼停止營運：創辦人信裡的三個理由

創辦人的信講了三個理由：AI 讓部署變簡單，成長遇到瓶頸；系統三年半來一路調整，複雜度與維護成本越來越高；下半年兩起資安事件，讓團隊看見安全與維運的不足。三個理由加在一起，最後的判斷是團隊承擔不了這份責任。

回頭看二月的共享叢集退場公告，會讀出另一層。那篇寫著共享叢集的計價「低於我們的成本價」、「我們一直在補貼這個服務」，並把 Zeabur 重新定位成「Your AI DevOps Engineer」。補貼中的舊架構、轉型中的新方向、再加上 AI Hub 在九月正式停止服務，這一整年其實都在收斂戰線。第二次事件是最後一根稻草，方向早在年初就看得出來。

社群的反應也很有代表性。轉貼停運信的討論串裡，有人說「錢都去 AI 了，新創 PaaS 太難混了，畢竟 PaaS 解決的部署運維問題，AI 也能解決部分」；也有人說「什麼都不懂，一直靠 Zeabur 來部署和管理專案，現在還有什麼可替代的嗎」。第二句話點出這次停運最大的受害族群：靠平台把複雜度藏起來的人。平台消失之後，那些被藏起來的複雜度會一次全部回到你手上。

我們對 Zeabur 的評價跟八月時差不多。八月那次他們公開了完整的攻擊路徑，這次也在一天內更正狀態頁、三天內說明停運安排，承認責任、給出時程，這在台灣新創圈並不常見。我們在 Zeabur 評價那篇稱讚過的部署體驗也是真的。問題在於，一個好用的產品和一個撐得起平台級安全責任的組織，是兩件不同的事。

給選 PaaS 平台的人：平台型服務一定要先寫好出口計畫

我們的立場很直接：選 PaaS 平台時，問「它會不會倒」沒有意義，該問的是「它倒了我要花幾天搬走」。任何平台都可能出事、轉型或關門，你能控制的只有自己的出口。

這不是 Zeabur 才有的事。2023 年初，CI/CD 平台 CircleCI 的事件報告寫到，一位工程師的筆電被植入惡意程式，攻擊者偷走登入工作階段，最後從部分資料庫帶走客戶的環境變數、權杖與金鑰，所有用戶被要求輪替存在平台上的秘密。2025 年，老牌的程式託管平台 Glitch 宣布停止專案託管，給了大約一個半月的時間，理由同樣是營運成本與濫用問題。平台型服務的風險有兩種：一種是資安，一種是存續，兩種都會落在用戶頭上。

這張表裡每一列，都對應到一篇我們寫過的延伸文章：秘密放在哪裡可以看企業秘密管理工具選購指南，資料備份與災難復原的 3-2-1 原則在資料備份完整指南，合約裡怎麼寫退場與資料返還，請看 SaaS 退場成本與合約條款。要重新挑平台，可以先看五大 PaaS 平台比較；如果你考慮直接改用 VPS 自己管，台灣 VPS 怎麼選有費用比較。

我們自己的做法很樸素：程式碼一律放在自己的 Git 倉庫，部署設定寫成檔案跟著程式碼走，資料庫每天備份到平台以外的地方，網域放在自己的註冊商。這次收到停運信，我們要做的是重新部署和切 DNS，不需要從平台裡把東西挖出來。搬家還是要花工，但這份工是可以估算的。

如果你的專案是用 AI 寫出來、用一鍵範本部署上去的，這次是一個很好的健檢時機。很多 Vibe Coding 的專案能跑，但沒人說得清楚它依賴了哪些服務、秘密放在哪裡。我們有一個 Vibe Coding 健檢服務在做這件事，搬家前先把底細摸清楚，搬起來會順很多。

看到這裡，如果你也在想「我們公司有哪些東西放在 Zeabur 上、該先搬哪個」，我們很樂意聽你聊聊現在的情況。我們自己正在做同一件事，可以陪你一起把專案清單、資料與秘密盤一遍，排出搬遷順序；後面真的要動手搬或重建，再談範圍跟費用。需要直接幫你把系統重新規劃部署，可以看客製化系統開發。