防暴筆記BREACH NOTES

一個使用者部署的聊天機器人，
一路走到平台的主資料庫

速讀：5 分鐘掌握重點

為什麼現在很紅：PaaS 最方便的地方，是你把所有密鑰都交給它保管。這份報告寫的是當平台本身被打穿時，那些密鑰會怎麼樣，以及為什麼平台自己隔了 24 小時才知道。

一句話結論
8 月 27 日，攻擊者利用一個使用者部署的 NextChat（v2.16.1，CVE-2026-7644）進入共用叢集，在路由快取裡拿到一位團隊管理員的平台 API 金鑰，再一路拿到內部服務的 AWS 金鑰、AWS root 金鑰、叢集管理員權限，最後連進正式資料庫。
他要的是什麼
他要的是平台幫所有使用者保管的那一大包密鑰。AI 供應商的 API 金鑰最好變現：直接拿去跑模型，帳單算在原主人頭上；報告和媒體都提到 Anthropic、OpenAI、OpenRouter 的金鑰被盜用。
你今天做一件事
如果你曾經把任何憑證放在這個平台的環境變數裡，不管有沒有收到通知，今天就列出仍然有效的那些，排進輪替。報告自己也這樣建議，而且要撤銷舊的，不是只建立新的。 直接去做 →
哪些能信
4 可證明2 推論3 缺口 每個主張都標了等級，缺口是誠實寫出來的。
破口速查
受害端一律去識別化；寫「未公開」代表公開資料查不到。
伺服器服務商
Zeabur（PaaS）；事件涉及東京區共用叢集（Kubernetes）、平台路由快取、平台的 AWS 帳號、正式資料庫
網路服務商
未公開
漏洞出現的地方
多層：使用者部署的 NextChat v2.16.1（CVE-2026-7644，MCP 功能的授權檢查）對外公開；共用叢集允許跨專案內部連線；路由快取裡存著平台 Legacy API Key；Legacy Key 沒有範圍與到期日；內部管理服務持有長期保留的 AWS root 金鑰；排程維護作業同時有正式環境私網連線與權限過大的資料庫憑證；監控沒有發現
馬上自我檢測
列出你放在平台環境變數裡、至今仍有效的所有金鑰（只列名稱與建立日期） aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent' 到各 AI／雲端供應商後台看 8 月 27 日以後的用量與金鑰清單
漏洞修補方式
平台端：多租戶網路隔離、快取不放憑證、API 金鑰要有範圍與到期日、刪除 root 金鑰、維護作業權限最小化、補齊特權變更與異常查詢告警。使用端：所有曾放在平台環境變數裡的有效憑證預防性輪替並撤銷舊的，金鑰綁範圍與預算上限
有 15 分鐘再看：其餘 2 點
  1. 被讀走的是部分正式資料庫，包括專案環境變數（名稱與值）與帳號資料：AI 與第三方 API 金鑰、雲端憑證、資料庫連線與密碼、簽章金鑰。即使變數改過名字，只要值符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI、Stripe 的格式，也在範圍內。
  2. 報告自承當時的監控與告警沒有發現，第一個訊號是 8 月 28 日 02:34 UTC 外部回報金鑰被盜用；第一次通知的範圍評估也是錯的。修補後新服務預設把環境變數存在使用者自己的專屬主機上，Legacy API Key 全面停用。

Zeabur 在 2026 年 9 月 9 日發布 8 月 27 日資安事件的完整報告：攻擊者從一個使用者部署、對外公開的 NextChat 進門，跨過共用叢集網路、平台 API 金鑰、AWS 帳號、正式環境四道邊界，讀走部分正式資料庫裡的專案環境變數。報告也寫明：當時的監控與告警沒有發現，是隔天外部回報金鑰被盜用才知道。

Zeabur 2026 年 8 月資安事件（官方完整報告）·2026-08-27 02:34 UTC 最早異常 → 08-28 02:34 UTC 接獲外部回報 → 09-09 完整報告、狀態頁結案·全文 11 分鐘
本篇目錄

發生了什麼

把 PaaS 想成一棟有管理員的公寓：你把鑰匙交給管理員保管，換來不必自己顧門。這份報告寫的是，有一戶房客自己裝的對講機有漏洞，有人從那裡進了大樓的公共管道間，在管道間撿到一張管理員的門禁卡，再用那張卡進了管理室，最後打開了放所有住戶備用鑰匙的保險櫃。

Zeabur 在 2026 年 9 月 9 日發布完整報告，同一天狀態頁標記事件結案。報告的第一手性質要先講清楚：這是平台自己寫的事後報告，所有時間都是 UTC，時間點是「最早確認的紀錄」，報告特別提醒，憑證第一次被使用的時間，不代表攻擊者就是那一刻拿到的。

  1. 2026-08-27 02:34 UTC
    最早確認的異常 API 請求與探測
    官方完整報告
  2. 02:36
    一位團隊管理員的 Legacy API Key 第一次被使用，查詢帳號與 AI Hub 資訊；02:37 建立第一把 AI Hub 存取金鑰
    官方完整報告
  3. 03:53
    第一次讀取專案環境變數的名稱與值
    官方完整報告
  4. 05:39 → 05:46
    讀到內部服務的環境變數（含 AWS 金鑰）並登入 AWS；接著讀到內部管理服務設定裡的特權 AWS 金鑰，以 root 使用者登入並開始列舉雲端資源
    官方完整報告
  5. 06:08 → 07:26
    在東京共用叢集建立異常的一次性作業；一個服務帳戶被授予叢集管理員權限
    官方完整報告
  6. 07:54
    資料庫中最早確認的入侵紀錄；11:52 起出現大量讀取專案環境變數
    官方完整報告
  7. 08-28 02:34
    接獲第一則 API 金鑰被盜用的回報，才確認事件
    官方完整報告
  8. 08-28 08:53 → 17:03
    發出第一次通知（報告承認範圍評估不正確）、第二次通知；AI Hub 預防性暫停
    官方完整報告、狀態頁
  9. 08-29 → 09-07
    與 AWS 溝通、補償審查、提供調查結果給主管機關、輪替內部憑證、發布重大安全更新
    官方完整報告、狀態頁
  10. 09-09
    完整報告發布，狀態頁結案
    狀態頁
  11. 09-22
    AI Hub 確定停止服務，未使用的實付額度退回為平台點數
    AI Hub 停止服務公告

從最早的探測到平台知道，中間是整整 24 小時；這 24 小時裡，攻擊者做完了上面每一格。

怎麼發現

報告的原話是：只在 8 月 28 日 02:34 接到 API 金鑰被盜用的回報後，才確認這起事件；當時的監控與告警沒有辨識出這次未授權存取。換句話說，第一個發現的人不在平台裡，是某個使用者或上游供應商看到自己的金鑰被拿去用了。

這一點比任何技術細節都值得停下來想：AWS root 金鑰被使用、服務帳戶被授予叢集管理員、正式資料庫被大量讀取，這三件事每一件都是告警規則最常見的範例。報告後來補上的監控項目，正好就是特權變更、異常雲端用量、可疑資料庫查詢。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是自己該做什麼，可以直接往「如何避免」繼續閱讀。如果你想知道攻擊者是怎麼一道一道跨過邊界的，下面開始進入技術拆解。

深入閱讀四道邊界，每一道是怎麼被跨過的

先講結論：入口是使用者的應用程式，但從第二格開始，每一格都是平台自己的設計問題，報告也這樣承認。

發生了什麼 · MITRE ATT&CK T1190
使用者部署、對外公開的 NextChat v2.16.1，利用 CVE-2026-7644（MCP 功能的授權檢查）。報告寫明，工作負載被打下之後攻擊者能走多遠，是平台的責任。
當時留下的訊號
對外服務出現異常的 MCP 相關請求。
能擋下它的控制
使用者端：更新版本、MCP 功能不對外。平台端：假設任何使用者工作負載都可能被打下。

狀態頁在 8 月 28 日另外提到 AI Hub 使用的 LiteLLM 有可疑活動，並因此暫停 AI Hub；完整報告的攻擊路徑裡沒有把 LiteLLM 列為其中一格。

整條鏈只有第一格是使用者的程式。其餘六格，每一格都是一個「平常應該不通、應該不存在、應該有人看到」的地方剛好通了、剛好存在、剛好沒人看到。

這次外洩了什麼

外洩分兩層：平台自己的憑證（用來一路往上爬的），以及使用者交給平台保管的憑證（最後被讀走的）。

leaked credentials這次外洩了什麼：服務、用途、存在形式
服務憑證類型用途存在形式放在哪權限範圍狀態
Zeabur 平台 APILegacy API Key（一位團隊管理員的）呼叫平台 API 管理專案API 金鑰平台的路由快取沒有範圍、沒有到期日；可讀專案環境變數、建立 AI Hub 金鑰Legacy API Key 驗證已全面停用
AWS IAM內部服務的 access key；內部管理服務的 root 使用者金鑰平台內部服務存取 AWS環境變數與服務設定中的明文金鑰內部服務的環境變數、內部管理服務設定root：整個 AWS 帳號內部管理金鑰已停用或輪替
正式資料庫排程維護作業的資料庫憑證維護作業連資料庫未公開排程維護作業權限超過所需資料庫密碼已輪替
使用者的第三方服務（AI、雲端、金流、資料庫等）專案環境變數的名稱與值：AI 與第三方 API 金鑰、雲端憑證、資料庫連線與密碼、應用程式簽章金鑰使用者的應用程式連外部服務明文環境變數（儲存於平台正式資料庫）平台正式資料庫狀態頁列出一串常見變數名稱，例如 AWS_ACCESS_KEY_ID、OPENAI_API_KEY、DATABASE_URL、JWT_SECRET；改過名字的變數，值符合 AWS、GitHub、Anthropic、OpenRouter、OpenAI、Stripe 格式者也在範圍內官方建議所有曾放在平台環境變數、仍然有效的憑證都預防性輪替，包括通知裡沒列到的
Zeabur AI Hub攻擊者建立的 AI Hub 存取金鑰攻擊者自用API 金鑰攻擊者手上報告表示沒有發現用量或費用全部撤銷；AI Hub 已停止服務
憑證本身已遮蔽或失效；這裡只說明它是哪個服務、拿來做什麼、以什麼形式存放，讓你能對照自己的環境。

最後一句建議是整份報告對使用者最重要的一句：不是「收到通知的才換」，是「曾經放在這裡、現在還有效的，全部換」。

證據等級

這篇幾乎所有事實都來自平台自己的報告與狀態頁。能證明的是「平台怎麼說」；平台沒說的部分，本站不補。

他們怎麼處理

確認之後的處理節奏，可以從狀態頁一路看下來。8 月 28 日當天撤銷被濫用的內部憑證、封鎖存取路徑、預防性暫停 AI Hub、發出兩次通知。接下來一週：與 AWS 溝通、審查補償申請、提供調查結果給主管機關、延長稽核與鑑識資料的保存、輪替所有內部憑證、更換共用叢集主機、把路由資料和使用者憑證分開。

中間有一段插曲：8 月 31 日的安全強化工作意外影響了 GitHub 整合、環境變數管理與寄信功能，狀態頁特別說明這不是新的入侵。9 月 3 日另有第三方安全稽核在進行。9 月 9 日完整報告發布，產品面的改變是把環境變數從平台的中央資料庫移到使用者自己的專屬主機（新服務預設，共用叢集上的服務不會自動切換）。

哪裡做對，哪裡做錯

做對的是報告本身的寫法：時間精確到秒、把「最早紀錄」和「實際取得時間」分開、主動承認第一次通知範圍錯誤、承認監控沒發現、把使用者程式的漏洞和平台自己的責任切開寫，並且直接建議所有仍有效的憑證都要換，不是只換通知裡列到的。這種坦白在平台事故報告裡不常見。

做錯的，報告自己列了八條，本站只想把它們排成一句話：每一道邊界都假設前一道會守住。共用叢集假設租戶不會亂連、快取假設沒人進得來所以放了憑證、API 金鑰假設不會外流所以沒設期限、內部服務假設不會被讀到所以留著 root 金鑰、監控假設異常會很明顯。報告也提到，出問題的共用叢集與 Legacy Key 正在退役中，隔離與存取控制還沒做完，這是最常見的一種破口：要淘汰的東西，最容易沒人管。

如何避免

當天就能做的，是平台使用者那一側：把所有曾經放在平台環境變數裡、現在還有效的憑證列成一張表（名稱、服務、建立日期、最後輪替日期），照報告的建議排進輪替。輪替時記得撤銷舊的，建立新金鑰不會讓舊金鑰失效。

一個月內，讓每一把金鑰都有範圍和預算上限：AI 供應商的金鑰設月用量上限與告警、雲端金鑰只給必要權限、資料庫帳號一個服務一組。能用短期憑證或從密碼管理器注入的，就不要以長期明文放在任何平台的環境變數裡。

這一季，如果你自己也在經營多租戶的服務，把報告的八條根因當成稽核清單：租戶間網路是否預設不通、快取和佇列裡有沒有憑證、API 金鑰有沒有範圍與到期日、root 或同等權限的長期金鑰是否存在、維護作業能不能碰到正式資料、特權變更和異常查詢有沒有告警，以及正在退役的系統有沒有人負責。

這篇提到的項目要花多少錢

公開資料沒有任何金額，下表把缺口列清楚，再列預防的成本。

cost平台被打穿：誰付了什麼
項目用量單價期間US$NT$舉證
使用者：被盜用的 AI API 金鑰用量
平台開放補償申請，8 月 30 日約 63% 申請通過審核；金額未公開
Anthropic、OpenAI、OpenRouter 等依各供應商牌價2026-08-27 起——狀態頁、INSIDE
Zeabur：補償與調查、第三方稽核——2026-08 → 09——官方報告（未列金額）
Zeabur：AI Hub 停止服務與退款未使用的實付額度退回平台點數，可申請改現金—2026-09-22——AI Hub 停止服務公告（未列金額）
攻擊者：建立的 AI Hub 金鑰
報告表示沒有發現 AI Hub 用量或費用
已建立、未產生用量—2026-08-270.000官方完整報告
使用者預防：盤點並輪替平台上所有有效憑證
估：取中間值 NT$27,500
約 1 人日（視服務數）顧問日費 NT$20,000–35,000（估）一次性859.3827,500本站假設值
使用者預防：AI 金鑰設預算上限與用量告警
估：多數供應商後台免費提供
約 0.25 人日顧問日費 NT$20,000–35,000（估）一次性214.846,875本站假設值
合計（僅可證明列）0.000
匯率假設 1 USD ≈ NT$32。單價為公開牌價或帳單實付，來源：Zeabur 官方完整報告、狀態頁、AI Hub 停止服務公告；本站人力日費假設（2026-10 查）。「舉證」欄標明每筆損失的證據來源與等級（ 可證明 推論 缺口）。

損失那幾格全是缺口，但使用者這一側的預防加起來大約一個多人日，而且不管你用哪個平台都一樣該做。

你可以學到什麼

站在攻擊者的位置看：他不需要找平台本身的漏洞。他只需要一個使用者部署的、有已知漏洞的應用程式，以及平台內部一連串「應該不會被碰到」的假設。打下一個平台，等於一次拿到上千個使用者的保險櫃。

lessons本案的 6 個教訓
  1. 01
    交給平台保管的密鑰，風險是平台所有邊界的總和。最好的保管方式，是讓它就算被讀走也用不了多少：有範圍、有預算上限、能快速撤銷。
  2. 02
    平台被打穿後，正確的輪替範圍是「曾經放在那裡、現在還有效的全部」，不是「通知裡列到的」。改過名字的變數，只要值的格式認得出來，一樣在範圍內。
  3. 03
    建立新金鑰不會讓舊金鑰失效。輪替一定要包含撤銷。
  4. 04
    root 金鑰、沒有期限的 API 金鑰、存在快取裡的憑證，這三樣只要存在，就是在等一條路接上它們。
  5. 05
    正在退役的系統最容易沒人管。退役期間的隔離和監控，要比正式運作時更嚴，而不是更鬆。
  6. 06
    如果第一個發現的是外部，代表告警沒有涵蓋最基本的訊號：root 登入、特權綁定、大量查詢。
keywords重點學習：最需要學習的 10 個關鍵字10 個
  1. 01
    多租戶隔離（multi-tenant isolation）
    共用叢集允許跨專案連線，是攻擊者從使用者容器走到平台內部的那一步。
  2. 02
    Legacy API Key
    存在快取裡、沒有範圍與到期日的平台金鑰；整條鏈的第一把鑰匙。
  3. 03
    AWS root 存取金鑰
    長期保留的 root 金鑰讓攻擊者一步拿到整個 AWS 帳號。AWS 官方建議根本不要建立。
  4. 04
    cluster-admin
    Kubernetes 的最高權限；服務帳戶被綁上它是報告中的持久化手法。
  5. 05
    環境變數（environment variables）
    PaaS 上最常見的密鑰存放方式，也是這次被大量讀走的東西。
  6. 06
    預防性輪替（preventive rotation）
    報告的核心建議：所有曾放在平台上、仍有效的憑證都換，不只通知裡的。
  7. 07
    撤銷（revocation）
    建立新金鑰不會讓舊的失效；輪替沒有撤銷，等於沒換。
  8. 08
    CVE-2026-7644
    NextChat MCP 功能的授權檢查漏洞，本案的入口。
  9. 09
    LLMjacking
    盜用 AI API 金鑰跑模型、帳單算在原主人頭上；本案最主要的變現方式。
  10. 10
    退役系統（legacy in retirement）
    共用叢集與 Legacy Key 都在退役中、隔離沒做完；最容易被忽略的破口。

下面五步全部唯讀，只列不改。不管你用不用這個平台，第一步和第四步都值得做。

try today今天就可以來試試約 15 分鐘

全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。

  1. 列出你放在任何 PaaS 環境變數裡的憑證：名稱、屬於哪個服務、建立日期（只列名稱，不印值）
    看到什麼代表什麼：列不出建立日期或上次輪替日期的，就是第一批要換的。這張表存成「env-credential-roster-r8.csv」，輪替一把就劃掉一行，撤銷那一欄也要打勾。
  2. 確認你的 AWS 帳號沒有 root 存取金鑰
    aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'
    看到什麼代表什麼：0 代表沒有；1 代表 root 有金鑰，平台被打穿時這把就是整個帳號。
  3. 到 OpenAI、Anthropic、OpenRouter 等後台看金鑰清單與 8 月 27 日以後的用量
    看到什麼代表什麼：看到不認得的用量高峰、或你以為已經換掉的舊金鑰還是有效，先撤銷再查。
  4. 看 AI 供應商帳號有沒有設月用量上限與告警
    看到什麼代表什麼：沒有上限的金鑰，外洩時損失沒有天花板。
  5. 如果你自己經營 Kubernetes：列出所有 cluster-admin 綁定
    kubectl get clusterrolebindings -o wide | grep cluster-admin
    看到什麼代表什麼：出現不認得的服務帳戶，就是這份報告第五格的痕跡。
想看全部細節？

環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 11 分鐘。

來源

本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。

ZeaburPaaSKubernetes多租戶隔離平台保管的密鑰平台事故報告
看完的心情
ai prompt把這篇的切入點帶回你的環境

複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。

預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。

§
對應課程模組

M2 身分與金鑰 · M5 偵測與告警 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。

延伸閱讀
newsletter
下一篇拆解直接寄到信箱

每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。

← 上一份代理說它要讀資料，實際上卻在改資料