Zeabur 環境變數外洩事件：哪些存取金鑰可能受影響？收到通知後的完整止損教學

Zeabur 在 2026 年 8 月 28 日公告，一組內部服務憑證遭未授權使用，攻擊者藉此取得部分專案的環境變數紀錄。API 是讓不同軟體互相呼叫功能的介面，API Key 則像是應用程式出示的通行證。環境變數是部署服務時，用來保存這類金鑰、資料庫密碼與其他設定值的欄位。簡單說，這次不是一般網站密碼外流，而是部分應用程式背後的「數位鑰匙」可能被看見。

如果收到 Zeabur 的通知信，最重要的動作不是只在 Zeabur 後台改掉欄位內容，而是先到憑證原本的發行平台撤銷舊 Key，再建立新 Key、更新服務並檢查異常紀錄。因為只改環境變數，已經外流的舊憑證仍可能繼續有效。

這起事件仍在調查。本文依據 Zeabur 官方狀態頁、創辦人林沅霖的說明，以及各服務商的官方安全文件整理。截至 2026 年 8 月 29 日 14：37（台灣時間），事件仍被標示為 Degraded，代表相關服務尚未完全恢復正常狀態。

Zeabur 環境變數外洩事件發生了什麼？

Zeabur 表示，團隊偵測到有人未經授權存取一組內部服務憑證，並使用它讀取專案環境變數紀錄。官方已在同一天撤銷該憑證、封鎖存取路徑並控制事件，也正在逐一通知可能受影響的使用者。

官方確認的環境變數名稱包含 OPENAI_API_KEY、ANTHROPIC_API_KEY、OPENROUTER_API_KEY、GEMINI_API_KEY、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、GITHUB_TOKEN、CLOUDFLARE_API_TOKEN、STRIPE_SECRET_KEY、DATABASE_URL、JWT_SECRET、MySQL、PostgreSQL、MongoDB 與 Redis 密碼等。其中 JWT_SECRET 是應用程式用來簽署登入權杖、判斷使用者身分的秘密字串。即使使用者自訂變數名稱，只要內容符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI 或 Stripe 的憑證格式，也可能落在已確認的曝險範圍。

這代表風險不能只用「AI token 被盜刷」理解。依照憑證權限不同，攻擊者可能消耗 AI 額度、讀寫雲端資源、接觸原始碼、呼叫付款功能、連線資料庫，甚至偽造仍然有效的登入憑證。實際能做到什麼，取決於每組 Key 原本被授予的權限。

Zeabur 同時表示，目前沒有證據顯示 Zeabur 帳號憑證、個人資料、伺服器資料、付款資料或信用卡資訊遭到存取。這句話的意思是「目前沒有發現證據」，並不等於調查已經結束，也不能用來排除第三方憑證遭濫用的可能性。

LiteLLM 是事故原因嗎？目前不能這樣下結論

Zeabur 在後續更新中提到，調查發現 Zeabur AI Hub 使用的 LiteLLM 出現可疑活動，因此暫停 AI Hub 服務以降低進一步影響。

LiteLLM 是一套 AI Gateway，也就是替應用程式統一轉接不同 AI 模型 API 的中介軟體。它會接觸模型供應商的憑證，因此一旦相關系統出現異常，本來就應該列入調查範圍。

但 Zeabur 的原文只說正在調查這些活動是否與事件有關，沒有把 LiteLLM 列為已證實的入侵起點。現階段能確定的是內部服務憑證遭未授權使用，以及環境變數紀錄被讀取；把事件直接寫成「LiteLLM 導致 Zeabur 外洩」會超過官方已公開的證據。

從資安角度看，這起事件嚴重在哪裡？

這不是單一使用者把 Key 放錯位置

依照 Zeabur 公開資訊，遭未授權使用的是一組內部服務憑證，而且它能讀取專案環境變數紀錄。這使事件更接近管理層或控制平面的憑證遭濫用，而不是某位使用者不小心把 .env 上傳到 GitHub。

這個差異很重要。使用者可以透過不把 Key 寫進程式碼、設定最小權限來降低個人風險；但如果部署平台內部具有跨專案讀取能力的憑證遭到濫用，單一平台憑證的權限範圍、不同租戶之間的隔離、敏感資料的存取稽核與異常偵測，就會直接影響事故半徑。

不過，現有公告不足以證明 Zeabur 的內部憑證可以讀取所有客戶、所有專案，也不能據此斷言租戶隔離失效。這些是後續事故報告應回答的問題，不是目前已證實的結論。

環境變數是存放方式，不是安全邊界

把秘密放在環境變數，確實比把 Key 寫死在原始碼安全，也能避免憑證跟著 Git 紀錄流傳。但只要部署平台、後台管理服務或內部權限可以讀取變數，環境變數仍可能被取出。它解決的是「不要把秘密放進程式碼」的問題，並不等於憑證已經被獨立加密、分權保管，或永遠無法被平台管理者讀取。

因此，這起事件不只提醒使用者輪替 Key，也提醒 SaaS 與 PaaS 平台：長效高權限憑證應該縮小作用範圍，敏感存取要留下不可任意修改的稽核紀錄，內部服務身分也要採最小權限與短效授權，而不是把「只有內部系統會用」當成安全保證。

初步應變有做到，但完整問責仍缺關鍵資訊

Zeabur 公開表示已在偵測異常當天撤銷憑證、封鎖路徑、通知可能受影響的使用者，並暫停出現可疑活動的 AI Hub。就第一階段的控制而言，這些都是必要且合理的動作；公告也具體列出多種可能曝險的憑證，比只說「部分資料受影響」更能協助使用者止損。

但截至 2026 年 8 月 29 日，官方尚未公開未授權存取的完整時間區間、受影響使用者與專案數量、資料是被全面讀取還是選擇性查詢、內部憑證為何會遭濫用、稽核日誌的完整程度，以及後續獨立檢視與賠償標準。現在的資訊足以要求使用者立即輪替憑證，還不足以對根因、完整影響或責任歸屬下最後結論。

收到 Zeabur 通知後，先做這 6 件事

1．先確認受影響的專案、服務與環境

查看 Zeabur 通知信列出的 Project、Service 與 Environment。Production 是對外服務的正式環境，Staging 則是上線前的測試環境，兩者可能使用不同憑證，不要只處理目前正在使用的主站。

若沒有收到通知，但曾把高權限憑證放在 Zeabur，也可以先盤點 Variables 頁面。不要把完整 Key 貼到群組、Email 或客服工單中，辨識時只記錄平台、用途、建立日期與遮罩後的末幾碼。

2．到原始平台撤銷舊 Key，不是只改 Zeabur 變數

API Key 是服務商核發的通行證。Zeabur 只負責把它注入應用程式，因此真正讓舊 Key 失效的地方，是 OpenAI、Anthropic、Google、OpenRouter、AWS、GitHub、Cloudflare 或 Stripe 等原始平台。

若憑證已確認曝險，安全優先的做法是立即撤銷舊 Key，接受短暫服務中斷，再建立替代憑證。若服務不能停機，可以先建立新 Key、部署並驗證，再立刻撤銷舊 Key，但兩把 Key 同時有效的時間必須盡量縮短。

3．更新環境變數後重新部署或重啟服務

把新 Key 寫入 Zeabur Variables 後，確認應用程式是否需要重新部署或重啟，才會載入新的環境變數。完成後做一個最低成本的功能測試，例如送出一筆小型 API 請求，確認服務恢復，再檢查舊 Key 已無法使用。

如果同一組 Key 還存在 GitHub Actions、其他雲端平台、本機 .env、CI/CD 自動建置與部署流程，或團隊密碼管理工具，也要同步更換。只修 Zeabur 內的一份副本，會讓其他部署繼續使用舊憑證。

4．從用量、帳單與日誌找異常

先記下平常每日用量，再比對事件前後是否突然出現陌生模型、異常 token 數、非預期費用、不同時區的請求或陌生 IP。Token 是模型處理文字時使用的計量單位，也會影響 API 費用。OpenAI 官方建議在懷疑 Key 外洩時刪除金鑰、檢查 Usage 並聯繫支援。Anthropic 也建議立即撤銷 Key，並檢查 Console 的 logs 與 usage。OpenRouter 則可以在 Activity 依 API Key、模型與供應商篩選歷史用量。

不要只看總金額。攻擊者也可能先用小額請求測試憑證是否有效，因此請求時間、模型、Key 名稱與來源位置同樣重要。

5．依憑證種類擴大檢查範圍

這張表反映一個重要差異：AI Key 外洩最容易先在帳單上被看見，但資料庫、雲端與付款憑證的影響不一定立刻出現費用。只查帳單，可能漏掉權限變更、資料存取或後門帳號。

6．保留證據並向 Zeabur 與服務商回報

若發現未授權用量，先截圖並匯出能取得的紀錄，再提交支援案件。至少保留以下資訊：

1. 發生時間與時區。
2. 異常金額、token 或請求數。
3. 使用的模型、API Key 名稱或遮罩後末碼。
4. Request ID（單筆請求的識別碼）、來源 IP、瀏覽器或應用程式類型、設備資訊。
5. 帳單、Usage、Security Log 與通知信截圖。
6. 撤銷舊 Key、建立新 Key 與恢復服務的時間。

Zeabur 創辦人表示，團隊會在完成必要調查與損失核實後處理後續賠償。不過，目前公開說明沒有列出統一賠償標準、時程或適用條件，因此應把相關紀錄完整提交到 Zeabur Support，並同步向發生異常的第三方服務商開立案件。

OpenAI、Anthropic、Gemini 與 OpenRouter 怎麼輪替？

OpenAI

前往 OpenAI Platform 的 API Keys 頁面刪除曝險金鑰，建立新 Key 並更新應用程式。接著在 Usage 與 Billing 檢查陌生用量；OpenAI 的帳號安全說明也建議在懷疑憑證遭入侵時立即聯繫支援。後續可改成每個專案或服務使用獨立 Key，方便追查來源並限制影響範圍。

Anthropic

登入 Claude Console，從 API keys 頁面刪除舊 Key，再建立替代金鑰。Anthropic 的官方安全指南建議立即撤銷疑似外洩的 Key，並在 Console 檢查 logs 與 usage。開發、測試與正式環境也應使用不同 Key。

Gemini

在 Google AI Studio 或 Google Cloud Console 建立新 Key、更新應用程式，驗證成功後停用或刪除舊 Key。Google 的Gemini API Key 指南也建議檢查 Cloud Console 的 API 用量與帳務紀錄，並替新 Key 加上 API 與來源限制。

OpenRouter

在 OpenRouter 的 Keys 頁面刪除舊 Key，再建立新 Key。接著到 Activity 依 Key 篩選模型、供應商、時間與費用；官方文件說明 Activity 可查看完整用量歷史。新 Key 可設定 spending limit，讓單一憑證即使再次曝險，也不會直接消耗整個帳戶餘額。

這次事件真正提醒了什麼？

把密碼放進環境變數，仍然比硬寫在程式碼或提交到 Git 安全，但環境變數不是不會外洩的保險箱。當部署平台、管理介面或具有讀取權限的內部憑證出問題，集中存放的 Secret 仍可能一次暴露。

對小型團隊來說，最實際的改善不是立即導入龐大的企業資安系統，而是先完成四件低成本工作：每個服務使用獨立 Key、只開必要權限、設定用量上限，以及保留一份憑證用途清單。下一次收到外洩通知時，團隊才能快速知道某把 Key 能做什麼、出現在哪裡，以及撤銷後會影響哪個服務。

若是正式產品，進一步把高權限憑證改成短效憑證、限制固定 IP，或存放在專用的 Secret Manager。AWS、GitHub、Cloudflare 與 Stripe 的官方文件都建議採最小權限、限制來源並定期輪替。這些控制不能保證永不外洩，但能把單一憑證被偷後的破壞範圍壓低。

常見問題

沒收到 Zeabur 通知信，還需要換 Key 嗎？

官方表示會直接通知受影響使用者。若沒有收到通知，但曾在 Zeabur 存放高權限或高額度憑證，可以先盤點用途並關注官方狀態頁；對停機成本低的服務，主動輪替仍是較保守的選擇。不要因為沒收到信，就忽略已經出現異常用量的帳戶。

只更改 Zeabur 的環境變數就安全了嗎？

不夠。你必須先讓原平台核發的舊憑證失效，再把新憑證更新到 Zeabur。否則攻擊者手上的舊 Key 仍可能繼續呼叫 API。

換 Key 後，原本服務會不會中斷？

若先撤銷舊 Key，服務會在新 Key 部署完成前短暫失效。若業務不能停機，可先建立新 Key、部署並測試，再立即撤銷舊 Key。已確認遭濫用的憑證應以止損優先，不宜為了維持服務而長時間保留。

需要更換 Zeabur 登入密碼嗎？

Zeabur 目前表示沒有證據顯示帳號憑證遭存取，而且官方文件顯示 Zeabur 使用 Google、GitHub 等第三方登入，沒有獨立的 Zeabur 密碼。仍可檢查第三方登入帳戶的安全紀錄、工作階段與兩步驟驗證，但這不能取代環境變數內各組憑證的輪替。

Zeabur 會賠償被盜刷的 API 費用嗎？

創辦人公開表示，團隊會在完成調查與核實損失後盡快進行後續賠償處理。目前尚無公開的統一金額、資格或完成時間。受影響使用者應保存服務商帳單、請求紀錄與處理時間線，分別向 Zeabur 和第三方服務商提交案件。

結論：先讓舊憑證失效，再談事故原因

這次 Zeabur 環境變數外洩事件最需要避免的誤區，是把處理範圍縮成 AI 帳單，或只在 Zeabur 裡貼上一把新 Key。官方已確認的變數類型橫跨 AI、雲端、原始碼、付款、資料庫與登入簽章，真正的止損必須逐一回到憑證發行平台，讓舊 Key 失效並檢查異常活動。

至於 LiteLLM 是否與入侵有直接關係、資料實際被如何使用，以及賠償如何執行，都要等 Zeabur 公布後續調查結果。現階段不必等完整事故報告才行動。對已收到通知的使用者來說，撤銷憑證、恢復服務、保存證據與回報損失，才是最能降低風險的順序。

資料來源

• Zeabur：Unauthorized Access to Project Environment Variable Data
• Zeabur 創辦人 Yuanlin 林沅霖 Threads 說明
• Zeabur：Setting Environment Variables
• Zeabur：How to get help from Zeabur team
• OpenAI：How can I keep my OpenAI accounts secure?
• OpenAI：Best Practices for API Key Safety
• Anthropic：API Key Best Practices
• Google：Using Gemini API keys
• OpenRouter：FAQ and usage monitoring
• AWS：Update access keys
• GitHub：Keeping your API credentials secure
• Cloudflare：Roll tokens
• Stripe：Best practices for managing secret API keys