台灣新創Zeabur爆資安事件正式資料庫遭存取部分用戶API Key與密碼遭讀取

09/10/2026

Zeabur 資安事件調查結果正式公布，攻擊者成功進入正式環境資料庫，並讀取部分用戶的 API Key、雲端憑證、資料庫連線資訊與密碼等敏感設定。

台灣雲端部署平台 Zeabur 近日公布 8 月資安事件完整調查結果，確認攻擊者成功突破平台多層系統防線，最終取得正式環境資料庫的存取權限，並讀取部分用戶專案所保存的環境變數，其中可能包含第三方 API Key、雲端服務憑證、資料庫密碼及應用程式金鑰等敏感資訊。

調查顯示，這起事件並非攻擊者直接突破 Zeabur 正式資料庫，而是從用戶部署在共享環境中的 NextChat 服務開始，接著利用平台內部權限與網路架構上的多個安全缺口逐步擴大權限，最後一路進入核心系統。

Zeabur 也坦言，NextChat 漏洞雖然是整起事件的最初入口，但平台本身未能有效限制遭入侵工作負載可以接觸的網路、資料與權限，同樣是造成影響範圍擴大的重要原因。

🚩NextChat漏洞成為第一個突破口

根據 Zeabur 調查，攻擊者最初鎖定部署於東京共享叢集中的一套 NextChat v2.16.1 服務。

攻擊者利用與 MCP 功能授權檢查不足相關的 CVE-2026-7644 漏洞，在容器內取得遠端程式碼執行（RCE）能力。

正常情況下，即使單一用戶部署的服務遭到入侵，影響範圍也應該被限制在該工作負載內。然而，當時共享叢集仍存在跨專案的內部網路連線，使攻擊者能進一步接觸保存路由資訊的快取系統。

問題也從這裡開始擴大。

該快取除了保存網域與服務對應資訊，還留有 Zeabur 過去使用的 Legacy API Key。攻擊者取得並批次測試這些金鑰後，發現少數仍然有效，其中甚至包含 Zeabur 團隊管理員所使用的高權限金鑰。

🚩舊版API Key缺乏權限限制　讓攻擊範圍快速擴大

Legacy API Key 是 Zeabur 早期提供 CLI 及自動化腳本使用的驗證方式，但相較於目前常見的權限設計，它沒有細分權限範圍（Scope）、缺乏明確有效期限，也無法針對不同資源及操作設定存取限制。

這代表一旦高權限金鑰遭取得，攻擊者能夠進行的操作範圍也會大幅增加。

取得管理員 API Key 後，攻擊者開始列舉 Zeabur 的內部專案及服務，並進一步讀取內部管理服務保存的環境變數。

調查人員也在這個階段發現另一項更嚴重的問題：內部服務環境變數中保存了多組 AWS 存取金鑰，其中甚至包括一組長期留存的 AWS root 使用者金鑰。

🚩AWS root金鑰遭利用　攻擊者取得共享叢集控制權

雲端稽核紀錄顯示，攻擊者取得 AWS 憑證後隨即進行測試，並利用 root 權限列舉 AWS 資源。

接著，攻擊者進入位於東京的共享叢集，建立異常的一次性工作，並將其中一個服務帳號提升至叢集管理員權限，進一步擴大對環境的控制能力。

值得注意的是，Zeabur 的核心系統實際部署在另一家雲端服務供應商，正式資料庫也沒有直接對公開網路開放。

照理來說，即使共享叢集失守，攻擊者仍不應直接碰到正式資料庫。

但調查發現，共享叢集內有一項負責清理服務的定時維運任務，基於工作需求可以透過私有網路連線至核心系統，而且這項任務持有的資料庫權限超過實際工作需求。

攻擊者控制共享叢集後，也因此取得通往正式環境的路徑，最終成功存取正式資料庫。

🚩API Key、資料庫密碼等敏感資訊遭讀取

Zeabur 確認，攻擊者曾查詢並讀取部分專案環境變數的名稱與內容。

受到影響的資料可能包括 OpenAI、Anthropic、Gemini及OpenRouter等第三方AI服務API Key，以及AWS、Cloudflare、DigitalOcean等雲端服務存取憑證。

此外，也可能涉及 GitHub Token、資料庫連線網址與密碼、JWT、應用程式簽章金鑰，以及其他存放於專案環境變數中的機密設定。

這類資訊一旦遭到取得，風險不只侷限於 Zeabur 平台本身。若相關憑證仍然有效，攻擊者可能進一步嘗試登入第三方服務、使用雲端資源或呼叫付費 API，因此受影響用戶仍需要重新產生及撤銷相關金鑰。

不過，Zeabur 表示，目前資料庫查詢紀錄確認的是部分專案環境變數遭到讀取，尚未發現攻擊者讀取其他類型正式資料庫內容的證據。

🚩約24小時後才發現異常　監控告警未及時發揮作用

此次事件也暴露出平台在異常偵測上的不足。

Zeabur 調查顯示，最早確認的異常 API 請求出現在 8 月 27 日，數小時後便已留下正式資料庫遭未授權存取的紀錄，當天也開始出現大量讀取專案環境變數的行為。

但直到隔日有用戶主動回報 API Key 疑似遭到盜用後，Zeabur 才正式確認發生資安事件，與最早發現的異常活動相隔約一天。

Zeabur坦言，當時既有的監控與告警機制並未成功辨識這些未經授權的存取行為。

事件曝光後，Zeabur先發出緊急通知，但由於初期掌握的證據仍不完整，第一次判斷的影響範圍並不準確，之後又再次向用戶補充最新調查結果。

🚩不只是單一漏洞　多個權限管理問題形成攻擊鏈

從完整調查結果來看，NextChat漏洞只是攻擊者進入系統的第一步。

真正讓攻擊者能一路從單一用戶服務進入正式資料庫的原因，是多個原本彼此獨立的安全問題串連在一起。

包括共享叢集存在跨專案連線、快取中保存平台憑證、舊版 API Key 沒有期限與細部權限限制、內部服務保存高權限 AWS 憑證，以及維運任務同時具有跨環境網路連線與過高的資料庫權限。

任何一項問題單獨存在時，影響可能有限，但當攻擊者能夠依序利用這些缺口，最終就形成一條從外部用戶服務一路通往核心資料庫的完整攻擊路徑。

🚩Zeabur全面停用Legacy API Key　要求用戶更換舊憑證

事件發生後，Zeabur已輪替或停用內部管理金鑰、資料庫密碼與快取密碼，全面關閉 Legacy API Key 驗證方式，同時切斷共享叢集通往正式資料庫的原有路徑。

平台也重新強化 API 授權機制，讓目前使用的 Access Token 能夠設定權限範圍及有效期限，並保留請求紀錄。此外，也針對高權限異動、雲端帳號異常使用與可疑資料庫查詢增加新的告警機制。

Zeabur也調整環境變數保存方式，讓專用伺服器用戶可以將環境變數完整移至自己的伺服器，不再存放於 Zeabur 中央資料庫；SSH密碼及私鑰也可由用戶選擇移除。

但這些措施只能避免後續風險，無法讓事件發生期間可能已遭讀取的舊憑證自動失效。

因此，Zeabur建議所有用戶重新檢查曾經保存於平台環境變數中的敏感資料，只要 API Key、Token、資料庫密碼或其他憑證目前仍然有效，都應考慮立即更換，同時檢查第三方服務的登入紀錄、API使用量與帳單是否出現異常。

此次事件也再次顯示，雲端平台的安全不能只依靠單一漏洞修補。從工作負載隔離、最小權限、憑證生命週期，到內部維運服務與正式環境之間的網路邊界，只要其中任何一層留下過大的權限，都可能成為攻擊者繼續向內部橫向移動的下一個跳板。

參考來源 : https://abmedia.io/zeabur-report-cloud-august-api