2026 年 8 月 28 日，Zeabur 在官方狀態頁公告：一組內部服務憑證遭到未授權存取，並被用來讀取專案環境變數紀錄。

平常躺在部署平台設定頁裡的 DATABASE_URL、OPENAI_API_KEY、GITHUB_TOKEN，看起來只是幾行讓服務順利啟動的文字。直到事故發生，開發者才會發現：它們不是一般設定，而是一串可以打開資料庫、程式庫、雲端資源與第三方帳單的鑰匙。

Zeabur 公告列出的環境變數名稱涵蓋 AWS、Cloudflare、GitHub、OpenAI、Anthropic、Stripe、資料庫連線、JWT 與私鑰等多種機敏存取資料。官方表示已在同日撤銷受影響憑證、封鎖存取路徑並控制事件，也會直接通知受影響使用者；但截至官方最後更新，調查仍在進行，Zeabur AI Hub 也因調查到 LiteLLM 相關可疑活動而暫停服務。

這不是一個只屬於雲端平台的抽象「供應鏈風險」。它剛好撞上使用 AI Agent 與 Vibe Coding 加速開發的年代：Agent 可以協助建立服務、串接資料庫、填入 API Key，再把應用程式推上正式環境；使用者卻不一定同步理解每一把鑰匙從哪裡來，又能開啟哪些資源。若想先了解 AI 輔助工具如何進入日常產品流程，可以延伸閱讀〈Claude Code 在產品開發中的應用〉。

本文的核心論點是：

AI Agent 降低了寫程式與部署的門檻，卻沒有降低憑證管理、權限控制與事故應變的責任。當憑證或機敏資訊外洩時，能不能快速止血，取決於你在事故發生前是否知道每一把鑰匙能開哪一扇門。

換句話說，使用 Zeabur 的門檻可以比直接管理 AWS 或 Google Cloud 低，但使用者仍需要具備同等層級的 IAM、最小權限、稽核與憑證生命週期意識。平台替你簡化部署流程，不代表它能替你承擔所有下游服務的資安責任。

先把已知事實與未知範圍分開

依據 Zeabur 官方事故公告，目前可以確認的內容包括：

• 未授權存取涉及一組內部服務憑證；
• 該憑證曾被用來讀取專案環境變數紀錄；
• 官方確認部分特定名稱的環境變數遭暴露；
• 即使使用自訂變數名稱，只要值符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI 或 Stripe 的可識別憑證格式，也在確認的暴露範圍內；
• 受影響使用者會收到包含專案、服務、環境與建議輪替項目的直接通知；
• 官方當時沒有發現 Zeabur 帳號憑證、個人資料、伺服器資料、付款資料或信用卡資料遭存取的證據；
• 調查尚未結束，LiteLLM 的可疑活動是否與事件有關仍在調查。

同樣重要的是，這份公告沒有證明所有 Zeabur 專案都受影響，也沒有證明未收到通知的人一定不受影響。它也沒有公布攻擊者實際使用了哪些下游憑證、造成多少費用，或讀取了哪些資料庫內容。這是本文對現有證據邊界的判斷，不是官方對未通知使用者的風險判定。

因此，社群貼文中的損失數字、攻擊路徑或責任歸因，在沒有其他證據前都不能當成已確認事實。包含「所有變數都已被整包取走」在內，也只能視為事故應變時需要防範的最壞情境，不能改寫成 Zeabur 已確認的影響範圍。

環境變數看似是設定，其實是一串跨服務鑰匙

一個 Vibe Coding 專案通常不是只靠一個服務運作。程式碼放在 GitHub，網站部署到雲端平台，資料存在外部資料庫，網域交給 DNS 供應商，文字或圖片功能再串接 AI API。

這些服務各自都有一把鑰匙，而部署平台的環境變數，經常成為所有鑰匙集中存放的地方。

這是假設情境： 如果一個正式服務同時保存全域 GitHub Token、可管理整個帳號的 Cloudflare Token、沒有用量限制的 AI API Key，以及具備管理權限的資料庫連線，那麼攻擊者只要取得同一組環境變數，就不只拿到一個網站的設定，而是獲得多條通往下游服務的路徑。

這也解釋了為什麼事故處理不能停在部署平台。平台可以封鎖原本的存取路徑，卻不能替使用者撤銷已經由其他供應商發行的憑證。

不要先改環境變數：先讓舊憑證失效

看到疑似外洩，最直覺的反應是登入部署平台，把 .env 裡的值換掉。這個動作有必要，卻不能排在最前面。

環境變數只是存取金鑰的其中一個副本。真正決定攻擊者還能不能使用它的，是發行金鑰的上游服務。即使把金鑰從 .env 或 Git 的提交紀錄中刪除，已經複製走的舊值仍然可以使用；只有到 AWS IAM、Google Cloud IAM 或其他原始供應商撤銷或更換，它才會真正失效。

不要只更換通知中點名的變數，也不要把輪替範圍限縮在 AI 服務 API Key，而應盤點同一受影響專案內所有承載機敏資訊的環境變數。變數名稱不一定能完整反映其權限與用途，因此仍需逐一確認實際內容。

這裡必須區分「應變範圍」與「已證實範圍」。擴大盤點與輪替，是在調查尚未結束時採取的保守風險控制，不代表已經證實每一個環境變數都遭到讀取；一般開關、顯示名稱等非機敏設定，也不需要為了製造忙碌感而無差別更換。

若你收到 Zeabur 通知，或有具體證據顯示憑證可能遭存取，立即依序處理：

1. 確認受影響範圍並保存證據。 記下 Zeabur 通知列出的專案、服務與環境，保存通知、時間、部署紀錄與供應商稽核紀錄。先避免無關的正式環境變更，以免破壞後續時間線。
2. 到憑證發行端撤銷舊值。 在 AWS、GitHub、Cloudflare、OpenAI、Stripe、資料庫或其他原始服務中停用舊憑證，而不是只刪除 Zeabur 裡的變數。
3. 建立權限更小的新憑證。 不要原樣重建一把帳號級、全域管理員權限的鑰匙。只授予該服務實際需要的資源與動作。
4. 更新所有合法使用者並重新部署。 包含正式站、背景工作、CI/CD、排程、Webhook 與本機維運腳本。漏掉任何一個消費端，都可能造成服務中斷。
5. 驗證舊憑證確實失效。 輪替完成不是「新服務可以跑」，還必須確認舊值已無法存取資源。

使用 Zeabur，也要有 AWS／Google Cloud 的資安意識

這裡引用 AWS 與 Google Cloud，不是要 Zeabur 使用者改學兩套 CLI，而是要帶入同一套雲端資安思維。AWS 的 IAM 安全實務強調臨時憑證、最小權限、定期檢查未使用的身分與權限；Google Cloud 也在 Service Account 安全實務中建議避免長效 Service Account Key，並以工作負載身分、稽核紀錄與細分權限降低外洩風險。

當你把 AWS、Google Cloud、GitHub、資料庫或 AI 服務的憑證填進 Zeabur 時，應先回答：

• 這把憑證是否只屬於一個服務與一個環境，而不是整個帳號共用？
• 它是否只有完成這項工作所需的權限，而不是 Owner 或 Administrator？
• 正式、測試與本機環境是否使用不同憑證？
• 憑證由誰負責、哪些服務正在使用、撤銷後會影響什麼？
• 上游供應商是否有可查詢的稽核紀錄、用量限制與異常告警？
• 能否改用短效憑證或工作負載身分，減少長效 Key 存放在環境變數中的需求？

這才是 AWS／Google Cloud 經驗對 Zeabur 使用者真正有用的地方：不要因為部署介面變簡單，就把環境變數當成不需要治理的設定值。Zeabur 管理的是部署入口，但每一把憑證的權限、生命週期、費用與下游資料，仍由使用者與原始供應商共同構成安全邊界。

事故發生時也要沿用同一套思路：在憑證發行端讓舊值失效、建立權限更小的新值、更新所有使用端、確認舊值無法再使用，最後從 AWS CloudTrail、Google Cloud Audit Logs 或其他供應商的稽核紀錄追查異常活動。這不是要求每位 Vibe Coding 開發者都成為雲端資安專家，而是要求任何把服務推上正式環境的人，至少知道自己的憑證能做什麼，以及出事時要去哪裡關掉它。

OWASP 的 Secrets Management Cheat Sheet仍保留作為跨供應商的共同原則：建立、輪替、撤銷與到期是一個完整的憑證生命週期。AWS 與 Google Cloud 的安全實務則證明，這些原則不是大型雲端平台才需要的繁複規範，而是任何正式服務都應具備的基本治理能力。

換句話說，止血不是把新值貼進設定頁，而是完成一個閉環：舊值失效、新值縮權、合法服務恢復、異常活動開始被追查。

輪替順序要看爆炸半徑，不是照字母排列

公告列出的項目很多，但它們的風險並不相同。建議先處理能建立更多權限、搬走資料或產生高額費用的憑證。

優先層級	類型	主要風險	立即動作
最高	雲端管理、GitHub PAT、部署與 DNS Token	建立資源、竄改程式碼、接管流量、建立持久存取	撤銷、檢查新建帳號／Token／資源、縮小新憑證權限
最高	資料庫連線與私鑰	讀取或修改資料、橫向移動	旋轉密碼／金鑰、限制網路來源、檢查查詢與登入紀錄
高	付款與 AI API 金鑰	代扣、偽造請求、消耗額度	撤銷、檢查用量與費用、設定限制與告警
高	JWT 與應用程式簽章金鑰	偽造 Session、Token 或簽章	更換簽章金鑰並評估使既有 Session 全部失效

這是風險分析，不是 Zeabur 公告提供的固定排序。 實際優先順序仍取決於每把憑證的權限、可存取資料、有效期限與目前是否出現異常活動。

接下來 24 小時：不要只看網站還能不能開

輪替只是阻止攻擊繼續使用舊憑證，不能回答它在失效前做過什麼。

這裡的「24 小時」是本文建議的緊急處理時間窗，不是 Zeabur 公告設定的官方期限。

接下來應從每個下游供應商收集同一段時間範圍的證據：

• API 使用量、來源 IP、User-Agent、地區與錯誤率是否異常；
• 是否出現陌生的使用者、Access Key、OAuth App、Webhook、部署或運算資源；
• GitHub 是否有未知 commit、workflow、deploy key、PAT 或 repository 設定變更；
• DNS、網域、CDN 路由與憑證是否被修改；
• 資料庫是否出現大量匯出、管理員登入、schema 變更或可疑查詢；
• AI、雲端與付款供應商是否出現不尋常用量或費用；
• 應用程式日誌是否出現異常登入、權限提升與資料存取。

OWASP 建議憑證管理系統至少記錄誰在什麼時間、為哪個系統與角色請求存取憑證，以及憑證何時被更新、由誰更新。這也是為什麼「我沒有看到異常」不能只靠網站畫面判斷；沒有可查詢的稽核日誌，本身就是一項需要補救的風險。

若查到個資或客戶資料遭存取，後續通知與法規義務會依資料種類、使用者所在地與適用法規而不同。本文無法從 Zeabur 公告判斷任何個別專案是否已達通知門檻，應保留證據並諮詢具備相應資格的資安與法律專業人員。

做到這裡，很容易得到一個聽起來痛快的結論：都是沒有資安觀念的新手太依賴 AI，才會在事故裡受傷。

但這個結論太簡單，也放錯了責任的位置。

支持新創，也要要求成熟的事故應變

先說清楚：平台內部憑證遭未授權存取，不是使用者採用 Vibe Coding 所造成的。把事故全部歸因於缺乏資安經驗的開發者，會模糊供應商端與使用者端各自需要改善的控制措施。

本文的目的不是責備 Zeabur。資安事件不會因為團隊是新創或成熟企業就完全消失；真正能被檢驗的，是事件發生後能否快速控制影響、持續調查、提供可執行的使用者指引，並把改善措施落實到系統與流程。對仍在成長的新創服務，社群可以給予完成調查與修復的時間，也應鼓勵團隊用透明、專業的方式重建信任。

支持新創與要求專業處理並不衝突。成熟的事故應變與危機溝通，至少應讓使用者持續取得以下資訊：

• 目前已確認的事實、仍在調查的項目，以及資訊更新時間；
• 受影響的服務與使用者範圍，無法確認時也要明確標示證據邊界；
• 使用者現在必須執行的動作、優先順序與驗證方式；
• 固定更新節奏，即使暫時沒有新結論，也應說明調查仍在進行；
• 調查完成後的事件時間線、根因、修復措施與防止再次發生的行動。

這裡所說的公關，不是用更漂亮的文字淡化事件，而是把技術調查轉成及時、準確、可採取行動的資訊。對新創而言，這套程序不是大型企業才需要的行政負擔，而是產品開始承載正式環境與使用者資料後，就必須具備的營運能力。

另一方面，使用者端的資安設計同樣重要。供應商端的控制措施影響事件能否快速被侷限，開發流程則會決定個別專案的傷害半徑與恢復時間。以下是工程分析：

第一，Agent 很容易把「能部署成功」誤當成「權限設定正確」。當文件要求一個 Token，它常會選擇最省事的全域金鑰，而不是建立受限於單一專案、單一環境與單一動作的憑證。

第二，環境變數常被當成無限容量的保險箱。只要應用程式可能用到，就把 GitHub、資料庫、DNS、AI 與付款金鑰全部放進同一個服務。結果是一個讀取面，連動多個供應商。

第三，Agent 能快速建立整條部署鏈，使用者卻未必知道金鑰的來源、擁有者、有效期限與消費端。事故發生後，沒有人敢撤銷，因為不知道會讓什麼服務停擺。

第四，缺少費用與異常告警時，濫用往往不是在第一個 API Request 被發現，而是在帳單、額度耗盡或客戶回報時才浮現。

問題因此不在「AI 寫的程式碼比較危險」，而在於 AI 讓團隊更快跨過原本會迫使人理解基礎設施的摩擦點。

這正是 Vibe Coding 年代最需要補上的認知：做出產品的門檻降低了，公開營運產品的責任沒有跟著降低。

長期防範：把 AWS／Google Cloud 的 IAM 思維帶進 Zeabur

Zeabur 與 AI Agent 可以替開發者降低部署與整合的操作成本，卻不會消除權限與憑證風險。實作時，可以把 Agent 當成一位沒有資安背景的新同事：它提出的憑證與權限設定必須經過人類檢查，不能因為部署成功就視為安全。

1. 每個服務、環境與用途使用不同憑證

正式與測試環境不能共用同一把鑰匙；前端、後端、CI 與維運工具也不應共用。分離後，單一憑證外洩不會直接擴散到所有環境，稽核紀錄也較容易指出來源。

2. 最小權限，並優先使用短效憑證

OWASP 建議對每組憑證套用細粒度的最小權限，並在可行時使用動態或會到期的憑證。對 Agent 而言，預設只提供開發環境的受限權限；需要正式環境寫入、帳務或權限管理時，再由人類針對單次任務核准。

3. 建立憑證清冊，不記錄憑證值

清冊至少要回答：

• 這把憑證由哪個供應商發行？
• 它能存取哪些資源？
• 哪些服務正在使用？
• 誰是負責人？
• 何時到期或輪替？
• 撤銷後如何驗證與回復？

清冊記錄的是 metadata 與依賴關係，不是把憑證值再複製到另一份試算表。

4. 讓費用告警與服務本身分離

只要供應商提供用量上限、預算或異常告警，就應設定合理門檻，並把通知送到不依賴同一套部署環境的管道。告警不能阻止外洩，但能縮短從濫用到發現的時間。

5. 限制 Agent 讀取與輸出機敏憑證

不要讓 Agent 預設讀取整份正式環境變數、把值輸出到 log，或將憑證貼進 issue、聊天與生成文件。Agent 的操作紀錄、shell history、CI output 與除錯截圖，也都應納入機敏資訊掃描範圍。

6. 定期做「撤銷演練」

選一把非關鍵憑證，實際走完建立新值、更新所有消費端、部署、驗證、撤銷舊值與回復的流程。若不能在可接受時間內完成，就代表目前的憑證管理設計還沒有事故應變能力。

一份可以直接照著走的檢查表

收到外洩通知後

• 核對官方通知中的專案、服務、環境與變數名稱
• 保存通知、部署、登入、API 與帳務紀錄
• 在上游供應商撤銷或輪替舊憑證
• 以最小權限建立新憑證
• 更新所有消費端並重新部署
• 驗證舊憑證已無法使用
• 檢查異常資源、帳號、Token、Webhook、流量與費用
• 評估 JWT、Session、Webhook 簽章與衍生憑證是否也要失效
• 記錄時間線、影響範圍、處置與仍未確認的問題

平常就要完成

• 正式、測試與本機環境使用不同憑證
• 每個服務使用獨立且受限的權限
• 優先採用短效或自動輪替憑證
• 維護憑證擁有者與消費端清冊
• 啟用機敏資訊掃描、稽核日誌、用量與費用告警
• 正式環境敏感操作要求人工核准
• 定期演練輪替、撤銷與服務復原

結論：Vibe Coding 可以快，但不能沒有煞車

Zeabur 事件提醒我們，環境變數不是風險的終點。它們往往只是通往 GitHub、雲端、DNS、資料庫、AI 服務與付款系統的鑰匙集合。

對 Zeabur 這類仍在成長的新創服務，合理的期待不是「永遠不發生事故」，而是事故發生後有清楚的負責角色、處理程序、通知節奏與改善紀錄。願意正視問題、持續更新並把修復轉成制度，才是值得鼓勵、也能重新累積信任的方向。

AI Agent 能替你建立應用程式，卻不會自動替你決定哪些權限不該給、哪一把鑰匙必須短效、帳單異常要通知誰，或外洩時先撤銷哪一個憑證。這些仍是產品擁有者與開發團隊的責任。

所以真正需要補上的，不是對 Vibe Coding 的恐懼，也不是用「新手活該」結束討論，而是一套跟得上生成速度的安全回饋迴圈：最小權限、憑證清冊、可稽核日誌、獨立告警，以及真正演練過的輪替流程。

回到文章開頭，那些躺在環境變數頁面裡的字串，從來都不只是設定。每一把鑰匙背後，都連著一項權限、一筆可能產生的費用，以及一份對使用者資料的責任。

程式可以用 prompt 快速生成；事故應變能力不能等事故發生後才開始生成。

---

參考資料與查證邊界

• Zeabur：Unauthorized Access to Project Environment Variable Data
• Threads：CabLate 對 Zeabur 事件應變與後續溝通的觀點
• OWASP：Secrets Management Cheat Sheet
• AWS IAM：Security best practices
• AWS CloudTrail：Working with CloudTrail event history
• Google Cloud：Handle compromised Google Cloud credentials
• Google Cloud IAM：Best practices for using service accounts securely
• Google Cloud IAM：Example logs for service accounts

本文依據 2026 年 8 月 29 日查閱到的 Zeabur 官方狀態頁撰寫。官方調查尚未結束，事故狀態、影響範圍與後續處置仍可能更新。