Zeabur 最近偵測到內部服務憑證遭未授權使用，攻擊者利用該憑證查詢儲存專案環境變數的資料。官方狀態頁已確認部分 API Key、雲端 Token、資料庫密碼與應用程式簽章密鑰暴露；Zeabur 創辦人林沅霖另在公開說明中表示，團隊已觀察到 Anthropic、OpenAI 與 OpenRouter API 金鑰被盜用。
收到 Zeabur 通知的專案、服務與環境，以及符合官方清單或可辨識憑證格式的有效金鑰，應直接進行撤銷與輪替。如果無法確定某個舊值是否落在相關範圍，可採保守做法一併輪替。重建新金鑰並不會讓舊金鑰自動失效；正確處置還包含撤銷舊憑證、檢查用量與帳單，再從雲端、資料庫與應用程式紀錄追查異常操作。
Zeabur 是什麼
Zeabur 是雲端部署平台，開發者可以從 GitHub 或預先建好的範本部署網站、API、Bot 與資料庫，平台處理建置、網域、TLS 憑證與執行環境等工作。
專案環境變數如何運作
Zeabur 專案內的 Variables 用來保存應用程式執行時需要的環境變數。環境變數的用途是把設定與原始碼分開。例如程式可以從 OPENAI_API_KEY 取得 API Key，不必將金鑰直接寫在 Git repository 裡；測試環境與正式環境也可以使用不同的值。資料庫連線字串、Stripe Secret Key、GitHub Token 與 JWT Secret 也常以同樣方式注入程式。
不過，「沒有寫進原始碼」不等於「平台無法取得明文」。應用程式要使用憑證，平台就必須在部署或執行時將它提供給服務。這次事件就發生在平台儲存與讀取這些 Variables 的路徑。
Zeabur 公開的事件時間線
Zeabur 的 事件狀態頁 表示，團隊偵測到一組內部服務憑證遭未授權存取，該憑證後來被用來取回專案環境變數記錄。官方表示在偵測到事件的同一天，已撤銷受影響的內部憑證、封鎖存取路徑並控制事件。
| 時間 | 已確認進展 |
|---|---|
| 偵測日未公開 | 偵測到內部服務憑證遭未授權使用；官方表示在同一天完成憑證撤銷與存取路徑封鎖 |
| 8 月 28 日 15:11 （台灣時間） | Zeabur 在狀態頁公開事件、憑證類型與輪替建議 |
| 8 月 29 日 01:42 （台灣時間） | 官方更新 LiteLLM 可疑活動，並預防性暫停 Zeabur AI Hub |
AI Hub 使用 LiteLLM。Zeabur 目前只確認調查期間發現 LiteLLM 的可疑活動，並正在確認它是否與本次事件有關。在正式事後報告公開前，不能把 LiteLLM 寫成已確認的入侵點或根本原因。
已確認暴露的憑證範圍
外洩範圍不限於名稱為 OPENAI_API_KEY 的變數。Zeabur 除了公開已確認暴露的變數名稱，也表示名稱經過修改，但值符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI 或 Stripe 可辨識憑證格式的變數也已確認暴露。
| 類型 | 官方列出的代表變數 | 可能影響 |
|---|---|---|
| AI API | OPENAI_API_KEYANTHROPIC_API_KEYOPENROUTER_API_KEYGEMINI_API_KEY | 盜用付費額度、產生異常用量與費用 |
| 雲端與網路 | AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYCF_API_TOKENDIGITALOCEAN_TOKENLINODE_TOKEN | 依憑證權限讀取、修改或建立雲端資源 |
| GitHub | GITHUB_PATGITHUB_TOKEN | 存取 repository、Actions、Package 或組織資源 |
| 付款 | STRIPE_SECRET_KEY | 依 Key 類型與權限讀取或操作 Stripe 資源 |
| 資料庫 | DATABASE_URLMONGODB_URIMYSQL_PASSWORDPOSTGRES_PASSWORDREDIS_PASSWORD | 連線資料庫，實際能做什麼取決於資料庫帳號權限與網路限制 |
| 應用程式機密 | JWT_SECRETPRIVATE_KEYCLIENT_SECRETSECRET_KEY | 偽造簽章、冒用應用程式身分，或解密由該機密保護的資料 |
Zeabur 創辦人 林沅霖在 Threads 公開說明 中表示，團隊已觀察到 Anthropic、OpenAI 與 OpenRouter 憑證被盜用，因此應優先處理這三類金鑰。這項「已觀察到盜用」的資訊來自創辦人公開說明；Zeabur 狀態頁本身只確認憑證暴露，並建議檢查異常用量與費用。
目前未發現遭存取的其他資料
Zeabur 表示，截至 2026 年 8 月 29 日尚未發現 Zeabur 帳號憑證、個人資料、伺服器資料、付款資訊或信用卡資訊遭存取的證據。這是調查進行中的現況，不應改寫成已經完成所有鑑識、可以確定這些資料完全沒有暴露。
另一個容易混淆的地方是 Stripe。「Zeabur 儲存的付款或信用卡資訊沒有發現遭取得」，不代表使用者放在 Variables 內的 STRIPE_SECRET_KEY 沒有暴露。後者已列在官方確認範圍，應依 Stripe 的金鑰類型、權限與 API 紀錄另行評估。
為什麼靜態加密擋不住這類事件
Zeabur 的 安全實務文件 寫著，正式資料儲存在 MongoDB Atlas，使用 AES-256 進行靜態加密，存取正式資料庫也受 Tailscale 網路限制。這些措施可以降低磁碟、備份或非授權網路存取的風險，卻不會讓應用程式無法讀取資料。
這次攻擊使用的是有效內部服務憑證。依目前資訊，事件較可能涉及服務身分、權限範圍與應用存取路徑，而不是攻擊者直接破解 AES-256。不過，Zeabur 尚未公開內部憑證如何遭取得、原始權限設計或完整根本原因，因此這一段只能視為根據已公開資料的推論。
曾在 Zeabur 儲存憑證的處置順序
收到 Zeabur 通知的專案、服務與環境，以及符合官方清單或可辨識格式的有效憑證，都應納入盤點。若無法確定某個舊值是否落在相關範圍，實務上可採保守做法一併輪替，但這不代表官方已確認所有歷史值都遭取回。
處置過程中應保留異常用量、帳單、request ID、Key ID、來源 IP、時間與稽核紀錄，再分別向 Zeabur Support 和憑證所屬平台提交工單。在保留證據前不要刪除日誌；撤銷憑證可以立即進行，沒有必要為了等待完整鑑識而讓舊 Key 繼續有效。
AI API Key 優先撤銷
依 Zeabur 創辦人公開說明，Anthropic、OpenAI 與 OpenRouter 已出現實際盜用，因此優先撤銷舊金鑰，再建立替代金鑰並重新部署服務。更新後還要確認執行中的 container、排程工作與備用環境已經使用新值，而不是只修改 Dashboard 上的 Variables。
OpenAI 的官方 API 文件提供以 API Key ID、Project 與時間分組的 Usage API，也提供專案 API Key 的列出與刪除功能。除了檢查 token 數，財務金額仍應以 Costs 或 Usage Dashboard 的 Costs 頁面對照帳單。
雲端、GitHub 與 Stripe 憑證
AWS、Cloudflare、DigitalOcean 與 Linode 憑證要先停用或撤銷，再從供應商保留的較早紀錄往後查，至少要涵蓋 Zeabur 公開通知前的期間。AWS CloudTrail 的 Event history 可以依 Access Key ID 與時間篩選管理事件，預設範圍是各 Region 最近 90 天的 management events，不包含 data events；後者需要原本已設定 trail 或 event data store。
GitHub 建議將暴露的機密直接視為已受損，刪除舊 Personal Access Token 後建立新 Token，並使用組織 Audit Log 追查特定 Token 進行過的操作。除了 repository 讀寫，還要檢查 Actions workflow、Deploy Key、Package、Webhook 與組織設定是否出現非預期變更。
Stripe 的 金鑰安全文件 建議暴露後立即輪替受影響金鑰；如果暴露範圍不清楚，應輪替帳戶中所有 Secret 與 Restricted API Key。同時檢查 API request log 的來源 IP、請求量與平常不會使用的 API。Stripe Publishable Key 原本就可以放在前端，風險不能與 Secret Key 混為一談；Webhook Signing Secret 也是另一種憑證，若曾放進 Variables 仍要獨立輪替。
資料庫密碼與 JWT Secret
資料庫連線字串往往同時包含帳號、密碼、主機與資料庫名稱。更換密碼後，應終止舊連線、檢查異常查詢與資料匯出，再確認該帳號是否擁有超出應用程式所需的權限。若資料庫原本只允許特定網路或 IP 連入，也要核對這些限制在事件期間是否有效。
JWT_SECRET 或其他應用程式簽章密鑰外洩時，單純更換新值可能還不夠。若系統使用該密鑰驗證現有 session 或 token，輪替後通常還需讓舊 session 失效，要求使用者重新登入。實際做法取決於應用程式的簽章演算法、Key ID、token 有效期與撤銷機制。
降低下一次憑證外洩的影響
環境變數仍是常見的機密注入方式，問題不是「以後不能使用 environment variables」。較務實的做法是限制每組憑證可以造成的影響，並確保發生異常時有足夠紀錄可以追查。
- 每個專案、環境與服務使用不同金鑰，不要讓一組 Key 同時跨越多個應用程式。
- 使用只有所需權限的 restricted key、IAM role 或資料庫帳號，避免預設給予管理員權限。
- 為 AI API 設定專案預算、速率限制與用量警示，縮短從盜用到發現的時間。
- 雲端與付款服務若支援固定來源 IP，可將金鑰限制在已知出口網路。
- 保留 API、雲端、資料庫與應用程式稽核紀錄，建立可以在短時間內輪替憑證的清單與流程。
如果服務必須拿到高權限長效金鑰，才能完成日常工作，這個架構本身就值得調整。改用短效憑證、workload identity 或雲端原生角色，能減少長期 Secret 被複製後可使用的時間；對個人專案而言，先從「每個服務獨立 Key＋最小權限＋用量上限」開始，通常比一次更換整套機密管理架構容易落實。MongoDB Atlas 以 OAuth 2.1 與短效授權降低長期憑證共用的做法，可參考本站的 MongoDB Atlas App Connections 介紹。
尚待 Zeabur 公開的調查結果
截至 2026 年 8 月 29 日，公開狀態頁尚未列出受影響使用者、專案與憑證總數，也沒有完整的暴露起訖時間。內部服務憑證如何被取得、原本可以讀取哪些資料、LiteLLM 可疑活動是否相關，也都要等正式事後報告。
因此，公開狀態頁可以確定憑證已暴露，創辦人公開說明則提到部分 AI Key 已被盜用；入侵根因與完整影響規模仍不能確定。處置憑證不需要等這些答案；把 LiteLLM 或任何單一元件寫成已確認的根因，反而會超出現有證據。
常見問答
怎麼知道自己的專案是否受影響？
截至 2026 年 8 月 29 日，Zeabur 公開狀態頁尚未提供可以由使用者查詢的完整受影響名單或 Dashboard 檢查工具。除了查看官方通知信，也要盤點現在的 Variables；對已刪除的歷史值，如果無法確定是否落在相關範圍，可採保守做法一併輪替。
沒有收到 Zeabur 通知信就不必輪替嗎？
不建議把沒收到通知當成安全證明。只要有效憑證曾存在 Zeabur Variables，就應納入盤點；官方也已確認部分名稱自訂，但值符合已知憑證格式的變數暴露。
只建立新 API Key 可以嗎？
不可以。舊 Key 沒有被撤銷、刪除或設為失效前，攻擊者仍可能繼續使用。正確步驟是撤銷舊值、建立新值、更新部署，再確認所有執行中的服務都已切換。
Zeabur 帳號密碼需要更換嗎？
Zeabur 目前表示沒有發現帳號憑證遭存取的證據，事件重點是專案 Variables 內的憑證。如果帳號密碼曾被重複當成環境變數使用、收到異常登入通知，或後續調查擴大影響範圍，仍應另行更換並檢查登入紀錄。
LiteLLM 是這次外洩的根因嗎？
還不能這樣說。Zeabur 只公開表示 AI Hub 使用的 LiteLLM 出現可疑活動，正在調查它是否與本次事件相關。AI Hub 暫停是預防措施，不是根因已確認的證明。
參考來源
- Zeabur：Unauthorized Access to Project Environment Variable Data
- Zeabur Security Practices
- OpenAI API：Usage
- OpenAI API：Project API keys
- GitHub Docs：Resolving alerts from secret scanning
- GitHub Docs：Identifying audit log events performed by an access token
- AWS CloudTrail：Viewing recent management events
- Stripe Docs：Best practices for managing secret API keys