Kelvin

外觀

語言

· 7 分鐘閱讀

台灣開發者愛用的部署平台，兩個月被駭兩次後關站（上）：從一個 NextChat 漏洞到 AWS root key

Zeabur 兩個月內被駭兩次後宣布關站。上篇拆解 8 月第一次入侵：攻擊者如何從一位使用者部署的 NextChat 漏洞，一路拿到管理員金鑰、AWS root 權限與正式環境資料庫。

10 月 17 日，一則消息在台灣工程師的 Threads 和 X 上傳開。工程師 Huli 寫道：「Zeabur 第二次被駭之後，倒了」。

Zeabur 的創辦人林沅霖在官方部落格宣布，平台將逐步結束營運，12 月 31 日全部停止。距離第一次被駭，不到兩個月。

如果你沒用過 Zeabur，這看起來只是一間新創收掉；但如果你曾經把 API key 放在任何一個部署平台上，這件事跟你有關。我分上下兩篇把它講完：上篇講 Zeabur 是什麼、第一次怎麼被打穿；下篇講第二次入侵、關站，以及我們能帶走的教訓。

一、Zeabur 是什麼？為什麼它被駭跟你有關？

Zeabur 是一個雲端部署平台（PaaS）。把 GitHub repo 接上去，它就自動建置、部署、配好網域和 HTTPS，資料庫也能一鍵開。創辦人說他想做的是「後端版的 Vercel」，這個專案起於他在浙江大學寫畢業專題的時候。

它在台灣開發者圈很常見：中文介面、有台北機房、n8n 這類工具一鍵就能架起來。根據 Zeabur 的說法，它在 2025 年 11 月完成 200 萬美元種子輪，當時已有 5,000 多位個人付費用戶。有開發者觀察到，不少人照著 AI 課程做出第一個網站，最後一步「部署上去」，示範的就是這類平台。

要理解這次事件，只需要懂一個詞：環境變數。你的程式要連資料庫、呼叫 OpenAI，需要密碼和 API key。這些不能寫進程式碼，所以大家把它們填在部署平台的環境變數設定頁。很方便，但也代表平台幫你保管了所有鑰匙。平台被打穿，鑰匙就一起被拿走。Zeabur 兩次被駭，攻擊者要的都是這個。

二、兩次入侵，先看全貌

  • 第一次（8/27）：攻擊者從某位使用者部署的 NextChat 漏洞進入平台內網，一路拿到管理員金鑰、AWS 最高權限，最後讀到正式環境資料庫裡的專案環境變數。（本篇主題）
  • 第二次（10/14–16）：攻擊者拿著一把 2024 年建立、從沒過期也沒換過的管理 token，從公網直接進入共享叢集，最後讀走 3,218,965 筆環境變數、321,810 個帳號資料。（下篇主題）

Zeabur 在 10 月事件初步報告裡寫得很直接：

這起事件的根本原因在 Zeabur：長期有效的管理憑證以明文保存，並可從公網使用。

三、第一次被駭：四道牆，一道一道被穿過

8 月 28 日早上 10 點半（台北時間，下同），Zeabur 收到一則回報：有使用者的 API key 被盜用了。團隊回頭翻紀錄才發現，攻擊者前一天就已經進來，在資料庫裡大量讀取使用者的環境變數，而監控系統什麼都沒發現。

最有意思的是，入口根本不是 Zeabur 自己的程式，而是一位使用者部署的開源聊天介面。Zeabur 9/7 發布的報告把攻擊路徑畫成四道邊界：

  1. 應用程式：有使用者在共享叢集上部署了 NextChat v2.16.1。這個版本的 MCP 功能授權檢查不足（CVE-2026-7644），攻擊者藉此在容器裡執行程式。
  2. 共享叢集內網：不同專案之間可以互連。攻擊者連到存放路由資訊的快取，而快取裡也存著 Zeabur 的 Legacy API Key。他批次測試這些 key，找到一把屬於「團隊管理員」的。
  3. 平台帳號與雲端帳號：Legacy API Key 是早期給 CLI 用的金鑰，沒有權限範圍、也沒有期限。攻擊者用它讀到內部管理服務的環境變數，裡面有一把 AWS root 金鑰。
  4. 核心正式環境：正式資料庫沒有公網入口，但共享叢集裡有個定期清理用的維護工作，剛好能透過私有網路連回核心系統，手上的資料庫帳號權限也比需要的大。攻擊者控制叢集後，兩樣都拿到了。

時間線（台北時間）：

  • 8/27 10:34：第一批異常 API 請求
  • 8/27 10:36：第一次用上團隊管理員的 Legacy API Key
  • 8/27 13:39–13:45：讀到內部服務設定，拿到 AWS root 金鑰並登入 AWS
  • 8/27 15:26：東京共享叢集裡一個服務帳號被授予叢集管理員權限
  • 8/27 15:54：資料庫裡最早的入侵紀錄；19:52 起出現大量讀取
  • 8/28 10:34：收到第一筆 API key 被盜用的回報
  • 8/28 16:53：第一封通知信（官方事後承認當時誤判範圍）；8/29 01:03 補發第二封

被讀走的是專案環境變數的名稱與值：AI 與第三方服務的 API key、雲端憑證、資料庫連線資訊與密碼、應用程式簽章金鑰等，還有帳號與 AI Hub 資訊。攻擊者也用管理員身分建立了 AI Hub 金鑰，但事後查無使用紀錄、沒有產生費用。

四、Zeabur 自己承認的問題

NextChat 的漏洞只是起點。官方報告說，讓使用者部署程式的平台，本來就該負責限制「某個使用者的服務被攻破後，攻擊者能碰到多少網路、資料與權限」。這次把傷害放大的，是四件事疊在一起：

  • 平台憑證放在路由快取裡，使用者的服務連得到。
  • Legacy API Key 沒有範圍、沒有期限。
  • 內部服務拿著超過需要的雲端權限，甚至是 AWS root。
  • 一個維護工作同時擁有跨環境的連線，和權限過大的資料庫帳號。

還有一個細節：共享叢集和 Legacy API Key 當時都在「淘汰中」。官方承認，淘汰中的系統在真正關掉之前，仍然要維持隔離與存取控制。很多團隊都有這種「反正快下線了」的舊系統，這句話值得記下來。

五、修補，和一句不完整的話

事後 Zeabur 停用了全部 Legacy API Key，切斷共享叢集連回正式資料庫的路徑，把路由資訊與使用者憑證分開，補上監控與告警。也推出一個新功能：專用伺服器的環境變數可以存在使用者自己的機器上，不再集中放在 Zeabur 的資料庫。

8 月的報告還寫著，所有內部管理金鑰都已停用或輪替。第二次入侵後，Zeabur 在 10 月的報告裡自己更正，承認這句話並不完整。

不過，那個「把環境變數搬到自己機器上」的新功能，在 10 月真的救了一批人。這留到下篇講。

六、如果你用過 Zeabur，現在就做這 4 件事

  1. 換掉所有放在 Zeabur 環境變數裡的 key 和密碼，就算 8 月換過也要再換。先到服務商那邊撤銷舊的，再建新的。
  2. 先換會燒錢的：AI API key、雲端帳號、金流金鑰；換完看帳單，順手設用量上限。
  3. 開始搬家：12/1 起共享叢集服務暫停、專用伺服器到期就關；12/31 全部停止，資料刪除。
  4. 退款和理賠分開申請：資安理賠 11/30 截止；餘額退款 11/30 前透過 Zeabur Support 開單，之後只能改用 email 申請。

上篇重點

  • 部署平台的環境變數頁，等於把所有鑰匙交給平台保管。
  • 多租戶平台上，別人的漏洞也可能變成你的漏洞；隔離做不好，一個聊天機器人就能通到整個平台。
  • 沒有範圍、沒有期限的金鑰，加上權限過大的內部服務，是讓傷害一路擴大的燃料。
  • 「快下線的舊系統」最危險：沒人想再投資它，但它還連著正式環境。

下篇預告：第二次入侵，攻擊者手上拿的是一把 2024 年 1 月建立、從沒過期、8 月也沒被換掉的管理 token。約 36 小時沒有任何告警，平台資料庫在 37 分鐘內被讀走。Zeabur 也在這之後宣布關站。下篇講第二次怎麼發生、關站時程，以及工程師該帶走的 6 個教訓。

一天之中的時刻，由 Zeabur 公布的 UTC 時間換算成台北時間（UTC+8）。只有日期、沒有時刻的項目，沿用 Zeabur 報告裡的 UTC 日期。文章與公告的日期，是官方網站上顯示的發布日期。

來源