Zeabur 2026 年十月資安事件

本文時間均為世界協調時間（UTC）。

2026 年 10 月 15 日 13:56，我們收到使用者回報，啟動調查。事後比對紀錄才知道，攻擊者早在 10 月 14 日 01:36 就開始使用 Zeabur 的內部憑證，比我們察覺早了約 36 小時。這段期間，攻擊者用的都是有效的憑證，走的也是 Zeabur 正式的存取管道，沒有觸發任何告警。

攻擊者從兩條路徑進入，10 月 15 日在 Zeabur 的內部網路會合，讀取了平台資料庫。這次被使用的憑證，八月事件後的輪替都沒有涵蓋。

你需要做什麼

請現在就處理，不必等通知信。已外洩的資料仍可能被利用，八月事件後換過的憑證，也要再換一次。

所有使用者

1. 更換環境變數中的所有憑證。包括 API 金鑰、雲端金鑰、資料庫密碼、簽章與加密金鑰。先到服務供應商撤銷舊的，再建立新的並重新部署。八月後已把環境變數遷移到自己專用伺服器的專案，這些變數不在這次平台資料庫的讀取範圍內，但主機本身遭入侵時，主機上保存的憑證仍要更換。
2. 重新登入並重新建立 Access Token。舊的平台存取權杖已全部撤銷。到 Access Token 管理頁面建立新的權杖，並檢查有沒有不明的請求。
3. zSend 使用者：重新建立 zSend API 金鑰。
4. GitHub 使用者：在 GitHub 稽核紀錄中，檢查 10 月 15 日 15:05 至 18:54 來自 Zeabur GitHub App 的操作，留意這些項目：
   • 非預期的 clone 或推送
   • 新增的 deploy key
   • 被修改的 webhook
5. 核對帳單。檢查各服務自 2026 年 10 月 14 日起的用量與帳單，GCP 專用伺服器使用者請回溯到 9 月 1 日。10 月 14 日是我們知道攻擊者最早使用憑證的時間，憑證可能更早就已外洩，有更早的紀錄也請一併檢查。

共享叢集使用者

1. 在資料庫內更換密碼。只改 Zeabur 上的環境變數，不會改到資料庫內的密碼。換密碼也不會讓已外洩的資料失效。資料庫存有你的使用者的密碼雜湊、登入工作階段或權杖時，請一併撤銷並重新產生。
2. n8n：更換 n8n 加密金鑰，並重新建立 n8n 內所有第三方憑證。
3. new-api／one-api：撤銷上游 AI 服務金鑰，並重新產生存取權杖。
4. PostgreSQL：檢查有沒有你不認得的角色、函式、觸發器、排程工作或擴充套件。有疑慮時，建立新資料庫，只匯入資料。
5. 台北（tpe1）與香港（hkg1）區域：把資料庫備份中的資料當作已外洩。

GCP 專用伺服器使用者

把伺服器當作已遭入侵：

1. 備份資料後重建伺服器。這是移除後門最可靠的方法。
2. 暫時無法重建時，至少：
   • 移除 /root/.ssh/authorized_keys 中註解為 @zeabur-pentest 或你不認得的金鑰。
   • 檢查 google-sudoers 群組、系統帳號、crontab、systemd 服務與 k3s 工作負載。
   • 更換 root 密碼，並關閉 SSH 的密碼登入。
3. 更換伺服器上的所有憑證，包括你自己的雲端憑證，並檢查對應帳單。
4. 對照入侵指標檢查登入紀錄，回溯到 2026 年 9 月 1 日。

Hetzner 與 DigitalOcean 專用伺服器使用者

在控制台檢查 10 月 14 日之後 root 密碼是否遭重設、系統是否遭重灌，並依上方 GCP 的檢查項目，確認沒有不明的登入方式。

影響範圍

各系統的細節如下。

平台資料庫

10 月 15 日 16:10 至 16:47，攻擊者讀取了上表列出的資料。帳號資料包含個人頁面上的資訊，例如電子郵件、使用者名稱與手機號碼。雙重驗證與通行金鑰的資料表只被查詢了統計資訊，沒有讀取內容的紀錄。平台存取權杖只存雜湊值，我們仍已全部撤銷。

攻擊者主要在找可以直接使用的 API 金鑰，特別是 AI 服務的金鑰：在環境變數與設定檔中搜尋 API 金鑰與私鑰、大量讀取 n8n 與 new-api／one-api 中的憑證，也試過用 Zeabur 的 AWS 金鑰呼叫 Amazon Bedrock。這是我們從指令內容與後續行為得出的觀察。攻擊者也讀取了帳號資料，所有讀到的資料，我們都當作已外洩。

八月事件後，Zeabur 為專用伺服器的使用者提供了指引與一鍵遷移功能：輪替憑證、刪除存放在 Zeabur 的環境變數與設定檔，改存到自己的伺服器。完成遷移的專案，這些資料只存在使用者的伺服器上，不在這次遭讀取的範圍內；尚未遷移的專案，環境變數仍存放在 Zeabur，這次也遭讀取。主機本身遭入侵造成的外洩不在此限，遭入侵的 GCP 專用伺服器仍要依你需要做什麼處置。

冒用帳號

10 月 15 日 16:12 至 17:19，攻擊者以兩個帳號的身分呼叫 Zeabur API，讀取帳號與專案清單，其中一個是 Zeabur 員工的帳號。這些請求沒有修改任何資源。

攻擊者讀取了用來簽發登入憑證的金鑰，我們研判登入憑證是用這把金鑰偽造的：平台存取權杖只存雜湊值，攻擊者又到 16:47 才大量讀取，解釋不了 16:12 就開始的冒用。20:25，我們輪替了簽章金鑰，所有使用者都已登出。

共享叢集的資料庫

攻擊者在 865 個資料庫的容器裡執行了讀取指令。稽核紀錄只記錄指令、不記錄輸出，部分指令也因錯誤而失敗，所以每個資料庫實際被讀走多少，無法確認。下表是我們依指令內容所做的判斷：

使用 PostgreSQL 的 n8n，我們檢查了 607 個，其中 602 個把加密金鑰寫在環境變數裡，n8n 內的第三方憑證因此等同以明文外洩。這些讀取發生在容器內部，八月事件後輪替的資料庫密碼，對這種讀取沒有防護作用。

東京（hnd1）區域另有至少 2 個 PostgreSQL 自 10 月 14 日 01:51 起被植入會回連外部的程式，其中一個到 10 月 15 日 16:24 仍有回連。入口是否為八月外洩的密碼，無法確認。我們在發現時已通知受影響的使用者更換憑證。

GCP 專用伺服器

攻擊者曾以 root 權限登入 101 台伺服器，最後一次登入是 10 月 15 日 20:36。攻擊者在其中 50 台加入自己控制的 SSH 公開金鑰，留下之後還能登入的管道，也在 Zeabur 的 GCP 專案內建立 5 台虛擬機器，把 16 份客戶伺服器的磁碟複本掛載上去。

這 101 台伺服器，我們都當作資料可能已外洩、也可能留有後門。我們已寄信通知受影響的使用者，並重設這些伺服器的 root 密碼。

Hetzner、DigitalOcean、Linode 與 Tencent Cloud

管理 Hetzner 與 DigitalOcean 客戶伺服器的權杖寫在內部程式碼與環境變數中，隨平台資料庫一起外洩。持有權杖就能重設密碼、重灌系統或複製磁碟。我們在 10 月 16 日 01:09 撤銷了全部權杖。兩家都沒有提供操作稽核 API，權杖是否遭使用無法確認。我們只排除了一件事：10 月 15 日 Hetzner 上的重設密碼與建立映像檔，是客戶本人和系統排程所做。DigitalOcean 沒有比對結果。

Linode 890 台伺服器中，有紀錄的 847 台沒有攻擊者登入。Tencent Cloud 的管理憑證沒有遭使用的紀錄。

GitHub App

10 月 15 日 15:05，攻擊者讀取了 Zeabur GitHub App 的私鑰。持有這把私鑰，就能存取使用者授權 Zeabur 存取的儲存庫。我們在 18:54 輪替私鑰。私鑰是否遭使用無法確認：我們沒有取得 GitHub 組織的完整稽核紀錄，向 GitHub Support 申請的紀錄也始終沒有回覆。

Zeabur 內部系統

攻擊者使用了多組 Zeabur 的 AWS 金鑰。大多數請求遭到拒絕，但攻擊者列出了兩個區域的使用者資料庫備份與原始碼上傳的內容，是否下載無法確認。攻擊者呼叫 Amazon Bedrock 的嘗試全部失敗，沒有產生費用。

對服務的影響

事件經過

攻擊者走了兩條路徑：路徑 A 從共享叢集進入 Zeabur 的 AWS 與機密管理服務，路徑 B 取得 GCP 專用伺服器的 root 權限。10 月 15 日，兩條路徑在 Zeabur 的內部網路會合。各步驟對應的 MITRE ATT&CK 技術，見附錄。

事件路徑

兩條路徑在內部網路會合。箭頭旁是攻擊者在每一步利用的憑證或缺口。

路徑 A　共享叢集與 AWS

起點

已持有 AWS 金鑰與叢集管理權杖

取得方式無法確認

管理權杖沒有期限，管理介面對公網開放

9 個區域的共享叢集

所有服務的環境變數、865 個資料庫容器

研判：權限過大的金鑰讀取舊叢集備份

AWS

機密管理服務的金鑰

已確認：讀取正式環境機密

Zeabur 機密管理服務

約 53 筆正式環境機密

包括內網管理憑證與資料庫帳號

路徑 B　GCP 專用伺服器

起點

一把舊的 GCP 服務帳號金鑰

外洩來源無法確認

研判：讀取初始化設定中的 root 密碼

GCP 專用伺服器

101 台伺服器的 root 權限

在遭入侵的伺服器上，用內網管理憑證加入節點

Zeabur 內部網路

一個帶有正式環境權限的節點

內網規則允許連線，再以內部唯讀帳號登入

Zeabur 平台資料庫

存放在 Zeabur 的環境變數、帳號與專案資料

路徑 A：從共享叢集到機密管理服務

1. 取得憑證。10 月 14 日 01:36，攻擊者開始使用 Zeabur 內部的 AWS 金鑰，01:40 開始使用共享叢集的管理權杖。這兩組憑證以明文保存在 Zeabur 的私有設定儲存庫中，和各叢集的連線位址寫在同一份設定裡。攻擊者如何取得，無法確認，推測見尚未證實的推測。
2. 進入共享叢集。管理權杖沒有期限，叢集的管理介面當時又對公網開放，攻擊者因此能從外部進入 9 個區域的共享叢集。01:51 起讀取部分系統機密，12:39 起範圍擴大到所有服務的設定與機密，包括環境變數。有完整讀取紀錄的區域已確認讀到內容，其餘區域我們一律當作已外洩。
3. 讀取使用者資料庫。13:40 起，攻擊者進到使用者資料庫的容器裡執行讀取指令：先是少數 new-api／one-api，15:41 起大量讀取 n8n，16:50 起逐表讀取部分 PostgreSQL，最後一個指令在 17:04。前後共 865 個資料庫服務，不是每個指令都成功。
4. 從備份取得機密管理服務的金鑰。攻擊者用叢集裡另一組權限過大的金鑰，讀取了一份舊叢集的備份（研判），備份裡有一組能讀取 Zeabur 機密管理服務的金鑰。
5. 讀取正式環境機密。10 月 15 日 14:52 至 16:51，攻擊者讀取了約 53 筆正式環境機密（已確認），包括內部網路的管理憑證、平台資料庫的帳號與 GitHub App 私鑰。

路徑 B：GCP 專用伺服器的 root 權限

1. 登入伺服器。10 月 14 日 13:40 起，攻擊者以 root 身分登入 Zeabur 代管在 GCP 上的專用伺服器，共 101 台。這些伺服器建立時，root 密碼以明文寫在初始化設定裡，設定完成後沒有清除。平台自己也要用這組密碼登入伺服器，所以保存的是明文，不是雜湊值。攻擊者持有的舊 GCP 金鑰能讀取這些設定，我們研判密碼就是這樣取得的。
2. 加入 SSH 金鑰。10 月 15 日 14:26 起，攻擊者用舊 GCP 金鑰修改伺服器設定，加入自己的 SSH 金鑰。15:05，攻擊者又從機密管理服務取得一把正式環境的 GCP 金鑰。
3. 換金鑰再試一次。我們在 17:17 停用舊金鑰，11 分鐘後，攻擊者改用新取得的金鑰再次加入 SSH 金鑰。17:31，我們也停用了這把。

這批登入發生在 10 月 14 日，比路徑 A 已知最早的正式環境機密讀取（10 月 15 日 14:52）早了一天多，所以路徑 B 的起點，不能用路徑 A 讀到的機密來解釋。同一批伺服器在 9 月 1 日至 5 日也曾有不明來源以 root 密碼登入，9 月 5 日當天約 98 台。是否為同一攻擊者，無法確認。

兩條路徑會合

1. 加入內部網路。10 月 15 日 15:30，攻擊者在一台遭入侵的 GCP 伺服器上，用路徑 A 取得的內網管理憑證，讓一個節點加入 Zeabur 內部網路。
2. 讀取平台資料庫。內部網路的規則允許這類節點連線平台資料庫。16:10 至 16:47，攻擊者以內部唯讀帳號讀取了平台資料庫（已確認）。
3. 移除節點。17:58，我們移除了這個節點。

平台資料庫遭讀取的結論，來自內部網路兩端的連線紀錄與資料庫日誌：這段期間的 29 個資料庫連線都能對應到這個節點，連線中的登入與查詢也能逐一追蹤，共 8,903 筆操作紀錄。

偵測

10 月 15 日 13:56，我們收到使用者回報，才啟動調查。這時距離攻擊者首次使用憑證（10 月 14 日 01:36）約 36 小時，10 月 14 日的攻擊活動也持續了超過 16 小時。

這段期間沒有任何告警：

• 攻擊者用的是有效的憑證，走的是 Zeabur 正式的存取管道，在紀錄中和正常的管理操作沒有差別。
• 當時沒有針對這類行為的告警，例如管理權限的異常使用、在容器內執行指令、大量讀取機密、內網加入新節點，或雲端金鑰從陌生來源使用。

處置

遏止

啟動調查後約 4 小時，我們移除了攻擊者的內網節點。10 月 15 日至 16 日的處置如下：

事件期間換上的金鑰仍遭使用

應變當天換上的憑證，有一部分後來還是遭攻擊者使用，問題出在叢集的每日備份。每日備份涵蓋叢集內所有資源，機密也在其中，而攻擊者在 10 月 15 日 15:04 讀取了備份的存取金鑰：

1. 15:40，我們換上新金鑰。
2. 16:00，每日備份收錄了這把新金鑰。
3. 18:51，我們刪除備份的存取金鑰。
4. 20:30，攻擊者使用了這把新金鑰。
5. 21:47，我們再次輪替受影響的憑證。

新金鑰被備份收錄、之後遭使用，這兩點已確認；攻擊者下載了這份備份，則是研判。20:30 用到的金鑰，也可能來自攻擊者在 18:51 之前就已取得的備份。

根除與復原

• 從 GCP 專用伺服器移除攻擊者的 SSH 金鑰，重設 root 密碼，並寄信通知受影響的使用者。
• 刪除攻擊者留下的磁碟複本、快照與測試資源。
• 撤銷所有使用者的平台存取權杖。
• 停用寫死在程式碼中的 Tencent Cloud、阿里雲與 Linode 憑證。
• 輪替其餘遭讀取的正式環境機密，包括平台資料庫的帳號密碼，並撤銷其他外洩的憑證。
• 保全各系統的稽核紀錄。
• 受影響的功能都已恢復，各功能的影響期間見對服務的影響。

根本原因

攻擊者一開始就持有 Zeabur 的叢集管理權杖與多組雲端金鑰。這些憑證保存在 Zeabur 的私有設定儲存庫中，沿用過往的做法，以明文保存。最可能的情況是這份設定儲存庫外洩，但外洩途徑無法確認，推測見尚未證實的推測。

讓攻擊者得以進入平台資料庫的缺口

• 管理權杖沒有期限，管理介面對公網開放。權杖在 2024 年 1 月建立後從未輪替，八月事件後的輪替也沒有涵蓋。
• 機密以明文保存。設定儲存庫、程式碼、共享叢集的服務設定與建置工作中，都有明文保存的金鑰。GCP 伺服器的初始化設定保存 root 密碼，這個問題我們 9 月 3 日就已發現，事發前還沒修正。10 月 3 日開始的機密遷移，事發時也還沒合併到主要分支。
• 備份保存所有機密，備份金鑰又和其他機密放在一起。攻擊者因此能從備份取得更多憑證，事件期間換上的部分憑證也被後續備份收錄。
• 權限大於用途。
  • 只需讀取單一儲存空間的金鑰，實際上能讀取整個 AWS 帳號內的儲存空間。
  • GCP 伺服器的預設服務帳號有專案層級的修改權限。
  • 內網規則允許帶有特定標籤的節點連線平台資料庫，而內網管理憑證能讓新節點直接帶上這個標籤。
  • 內部唯讀資料庫帳號能讀取所有資料。
  • 已停用服務的部署金鑰，在服務停用四個月後仍然有效。
• 內部服務與使用者服務部署在同一個叢集。攻擊者讀取使用者設定時，也一併取得了內部服務的憑證。
• 偵測與紀錄不足。攻擊持續約 36 小時都沒有觸發告警，見偵測。儲存空間、GCP 與 GitHub 的存取紀錄不完整，部分存取與影響範圍無法查明。

與八月事件的關係

這是 Zeabur 不到兩個月內的第二起資安事件。許多使用者在八月後照我們的指引做了調整，也想知道：既然做了這些，為什麼還會發生，兩起事件又有沒有關聯。

八月後做了什麼。我們輪替了當時確認外洩的內部金鑰，並停用 Legacy API Key。產品上，專用伺服器的專案可以把環境變數與設定檔遷移到自己的伺服器，也可以刪除 Zeabur 保存的 SSH 憑證，並查看 SSH 登入紀錄。八月事件的通知與公告也建議使用者輪替憑證、刪除存放在 Zeabur 的環境變數與設定檔，並遷移到自己的伺服器。

為什麼還是發生。八月的輪替沒有涵蓋設定儲存庫中以明文保存的叢集管理權杖與 AWS 金鑰，GCP 伺服器初始化設定中的 root 密碼也還沒修正，而這次攻擊者用的正是這些憑證。八月事件報告寫「已停用或輪替所有內部管理金鑰」，這個說法並不完整，我們在此更正。

檢討

做對的地方

• 依八月指引完成遷移的專案，環境變數與設定檔只存放在使用者自己的伺服器上，不在這次平台資料庫遭讀取的資料中。
• 啟動調查後約 4 小時，我們移除了攻擊者的內網節點，當天也封鎖了叢集管理介面與 GCP 專用伺服器的公網連線。
• 內部網路兩端的連線紀錄與資料庫日誌完整，平台資料庫的讀取範圍能逐筆確認。

做錯的地方

• 八月事件後的輪替沒有涵蓋這次被使用的憑證，八月事件報告的說法也不完整，見與八月事件的關係。
• 9 月 3 日已發現 GCP 伺服器的初始化設定保存 root 密碼，事發前沒有修正。
• 應變當天換上的金鑰被每日備份收錄，部分後來仍遭使用，見事件期間換上的金鑰仍遭使用。
• 攻擊持續約 36 小時，最後是使用者回報才發現，見偵測。

後續改善

Zeabur 將在 2026 年 12 月 31 日停止營運，以下只列已執行的改善。

沒有查明的事

無法查明的事項

以下事項受限於現有紀錄，到本文定稿時仍無法查明。無法排除遭存取的資料與憑證，我們都當作已外洩處理。

• 最初的憑證從哪裡來。GitHub 稽核紀錄只記錄壓縮檔下載，沒有 clone 操作。紀錄顯示 8 月 30 日與 9 月 2 日，有人用員工的 GitHub 授權下載了設定儲存庫，但無法確認是誰。我們向 GitHub Support 申請完整紀錄，最終沒有得到回覆。
• 舊 GCP 金鑰從哪裡外洩。我們查過 git 歷史、機密管理服務與舊叢集備份，都沒有找到外洩點。9 月初以 root 密碼登入 GCP 專用伺服器的 31.57.201.201 是否為同一攻擊者，也沒有結論。
• 共享叢集資料庫實際被讀走多少。稽核紀錄保留了指令，沒有記錄輸出，我們只知道攻擊者下過哪些指令。
• 備份與儲存空間物件的下載範圍。遭入侵主機上的證據確認，攻擊者在 10 月 15 日 15:42 透過預先簽署的下載網址，取得了客戶資料庫備份。這和含有內部憑證的叢集備份是兩回事。台北（tpe1）與香港（hkg1）的資料庫備份，以及原始碼上傳的儲存空間，只確認物件清單被列出過。當時沒有啟用物件存取紀錄，是否遭下載無法確認。舊叢集備份是否遭讀取，同樣沒有直接證據，仍維持研判。
• GCP 資源的讀取範圍。GCP 專案當時沒有啟用資料存取稽核紀錄，只有寫入操作的紀錄，事後也沒有其他方式補查。
• Hetzner 與 DigitalOcean 權杖是否遭使用。兩家都沒有提供操作稽核 API。除了 10 月 15 日 Hetzner 上已確認是客戶本人和系統排程所做的操作，其餘無法確認。
• GitHub App 私鑰是否遭使用。我們沒有取得 GitHub 組織的完整稽核紀錄，GitHub Support 也沒有回覆。
• 平台資料庫的查詢回傳了什麼。我們已確認攻擊者執行的查詢、其中 7 個主要查詢回傳的筆數，以及有 14 個集合回傳了資料，主要查詢都讀到了最後一筆。資料庫日誌沒有記錄回傳內容，我們也無法得知攻擊者之後如何保存或使用這些資料。
• 部分叢集的活動範圍。台北（tpe0）叢集，以及攻擊者曾建立資源的專用叢集，稽核紀錄不完整，之後也沒有再調查。
• 10 月 14 日之前發生了什麼。共享叢集與 AWS 的紀錄中，10 月 14 日 01:36 之前沒有使用有效憑證的活動。後來濫用憑證的部分 IP，10 月 10 日起已出現在未登入的 Zeabur API 存取紀錄中，但這些 IP 可能是多人共用的代理伺服器，光憑 IP 相同無法確認是同一人。10 月 13 日另有針對專用伺服器的 SSH 登入嘗試，都沒有成功。這段期間是否有資料外洩，無法確認。

尚未證實的推測

以下是我們認為最可能的解釋。它們有間接證據支持，但缺少直接紀錄，不能當作事實引用。到本文定稿時，這些推測都沒有得到證實，也沒有被推翻。

推測 1：最初的憑證來自八月事件

• 推測：攻擊者利用八月事件外洩的 GitHub App 私鑰，取得了 Zeabur 私有設定儲存庫的內容，包括 10 月 14 日使用的 AWS 金鑰與叢集管理權杖。沒有任何證據直接證明這條路徑，以下只是時間與能力上吻合的間接線索。
• 哪些換了、哪些沒換：
  • GitHub App 私鑰，已更換。八月事件中，這把私鑰在 8 月 27 日遭讀取。依 GitHub 稽核紀錄與機密管理服務的版本時間，私鑰在 8 月 31 日更換，可被利用的期間約 4 天。這個 App 安裝在 Zeabur 的 GitHub 組織上，持有私鑰就能讀取組織內所有儲存庫。
  • 設定儲存庫中的明文憑證，沒有更換。10 月 14 日攻擊者最先使用的 AWS 金鑰與叢集管理權杖，8 月 27 日時已經以明文存在設定儲存庫中。八月事件後我們只更換了私鑰，沒有更換這些憑證，到 10 月 15 日事件應變時才停用。所以即使私鑰已經更換，只要有人在 8 月 27 日至 31 日間取得了儲存庫內容，裡面的憑證到 10 月都還有效。
• 其他支持的線索：
  • 攻擊者嘗試讀取的部分內部機密名稱，只出現在另一個內部儲存庫中。攻擊者可能同時持有兩個儲存庫的內容，這與 App 私鑰的組織層級權限相符。
  • 10 月 14 日 01:36 之前，共享叢集與 AWS 沒有有效憑證的使用紀錄，後來濫用憑證的 IP 在 Zeabur API 上也都沒有登入。這符合「只持有儲存庫中的憑證」的情況。
• 不支持的線索：八月事件與這次事件的攻擊者 IP 沒有重疊。
• 為什麼無法證實：我們向 GitHub Support 申請了 8 月 27 日至 31 日間這個 App 簽發的存取權杖、設定儲存庫的 clone 與下載紀錄，以及 8 月 30 日與 9 月 2 日以員工授權下載設定儲存庫的來源，GitHub Support 最終沒有回覆。員工授權的下載，也不能排除是另一條取得管道。

推測 2：10 月 14 日前的探測是同一攻擊者的偵察

• 推測：10 月 10 日至 13 日的匿名探測與 SSH 嘗試，是同一攻擊者在使用憑證前的偵察。
• 支持的線索：
  • 103.237.102.191：10 月 10 日 18:27 未登入瀏覽 Zeabur，10 月 14 日以管理權杖存取共享叢集。
  • 23.106.46.239：10 月 12 日 12:52 起未登入大量嘗試 Zeabur API，10 月 13 日嘗試 SSH 登入專用伺服器，10 月 14 日 01:36 首次使用外洩的 AWS 金鑰。
• 為什麼無法證實：攻擊者大量使用代理伺服器，同一個 IP 可能由不同人共用，僅憑 IP 相同無法確認是同一人。

推測 3：10 月 15 日的部署金鑰存取是攻擊者所為

• 推測：10 月 15 日 15:02，一把已停用服務的部署金鑰讀取了設定儲存庫，研判為攻擊者所為。
• 支持的線索：這筆存取發生在攻擊者讀取正式環境機密期間（14:52 至 16:51），而金鑰所屬的服務已停用四個月，不應有正常存取。
• 為什麼無法證實：沒有紀錄能把這筆存取直接連到攻擊者。

附錄

時間軸

攻擊者活動與我們的應變

10 月 14 日至 15 日，各系統上的攻擊者活動與我們的處置，以 UTC 時間繪製

攻擊者的操作

攻擊者有存取權、沒有連續紀錄

我們的處置

啟動調查

共享叢集管理介面

使用者資料庫容器

AWS 金鑰與機密

GCP 專用伺服器

內部網路與平台資料庫

帳號與第三方金鑰

10/14

06:00

12:00

18:00

10/15

06:00

12:00

18:00

入侵指標

在你的系統或服務供應商紀錄中發現下列指標時，請把相關憑證當作已外洩，並聯繫我們。攻擊者大量使用輪替的代理伺服器，下表只列代表性的位址。可信度採 STIX 的 0 到 100 數值：已確認為 85，研判為 60，無法確認為 30。機器可讀的版本見 STIX 2.1 檔案，其中的 IP 指標有效期到 2027 年 1 月 13 日。

MITRE ATT&CK 對照

依 MITRE ATT&CK 的戰術排列。

名詞說明

• 共享叢集（Shared Cluster）：多位使用者的服務一起執行的 Kubernetes 叢集。我們已在 2026 年 2 月公告退場，受影響的服務都在公告前部署。
• 專用伺服器（Dedicated Server）：由 Zeabur 代管、只執行單一使用者服務的伺服器。
• 管理權杖：能管理整個叢集的憑證，持有者可以讀取所有服務的設定，並在任何容器內執行指令。
• 機密管理服務：Zeabur 用來集中保存正式環境機密的 AWS 服務。
• 內部網路：連接 Zeabur 正式環境服務的私人網路（Tailscale），平台資料庫只接受這個網路的連線。
• 平台資料庫：保存所有帳號、專案、服務與環境變數的 Zeabur 正式資料庫。

支援與費用

需要協助，或發現異常存取與不明費用，請透過 Zeabur Support 聯繫我們。聯繫前請先撤銷相關憑證，只提供遮蔽後的資訊，不要在工單或公開管道貼出仍有效的金鑰或密碼。

外洩的憑證遭盜用時，你可能需要承擔額外的費用，對此我們深感抱歉。在目前的財務條件下，Zeabur 無法支付本事件衍生的第三方服務費用。多數雲端與 API 服務供應商設有申訴或減免管道，你可以把這份報告附給供應商作為說明。供應商要求其他證明時，請透過工單告訴我們，我們會盡力提供。帳戶餘額退款不受本事件影響，詳見10 月資安事件後續處理說明。

Zeabur 已宣布將於 2026 年 12 月 31 日停止營運，這是營運上的決定。在那之前，我們會持續處理本事件的支援申請。

攻擊者開始使用憑證約 36 小時後，我們才從使用者的回報得知這起事件。保護你存放在 Zeabur 的憑證是我們的責任，我們沒有做到。我們向所有受影響的使用者致歉。

Zeabur 團隊