第二次被打穿的，是上一次沒換的那幾把

發生了什麼

2026 年 10 月 15 日 13:56（UTC），平台收到使用者回報，啟動調查。這時候攻擊者已經在系統裡待了約 36 小時：第一次使用平台內部的 AWS 金鑰是 10 月 14 日 01:36，中間沒有任何告警響過。

這是同一個部署平台不到兩個月內的第二起資安事件。八月那次，攻擊者從一個使用者部署的應用程式一路走到平台的正式資料庫（拆解在這裡）；三天前我們也把這個平台三年來的公開紀錄排在一起，談「介面變簡單、危險不能跟著變輕」（那篇）。這篇接著寫第二次。

先講這份文件的性質。這篇根據的是平台在 10 月 19 日發布的初步報告，報告開頭就寫明調查還在進行、會隨進度更新。它有一個值得肯定的地方：每個主張都標了確定程度，「已確認」是有日誌直接記錄，「研判」是時間與內容吻合但缺直接紀錄，「推測」則集中放在獨立一節，並寫明不能當事實引用。我們沿用它的分法，報告標「推測」的，這篇一律標 inferred 或 gap。

報告公布的數字：平台資料庫裡的服務環境變數（名稱與值）3,218,965 筆、帳號 321,810 筆（電子郵件、使用者名稱、手機號碼等）、明文的郵件服務 API 金鑰 566 把、平台存取權杖 11,536 筆（只有雜湊值）。共享叢集 9 個區域的服務設定與機密，以及 865 個資料庫服務的容器內被執行過讀取指令。代管於 GCP 的專用伺服器 101 台被以 root 登入，涉及 92 位使用者。

10 月 17 日，創辦人發布停止營運公告：部分服務 12 月 1 日起陸續停止，所有專用伺服器與共享叢集 12 月 31 日前關閉。

1. 2024-01-10
   共享叢集的管理權杖建立，沒有期限，之後從未輪替
   官方初步報告時間軸
2. 2026-01-20
   這把管理權杖以明文寫進平台的私有設定儲存庫
   官方初步報告時間軸
3. 2026-08-27
   八月事件：平台的 GitHub App 私鑰遭讀取（8 月 31 日更換）；設定儲存庫裡的明文憑證沒有輪替
   官方初步報告
4. 2026-09-01 至 09-05
   不明來源以 root 密碼登入約 98 台 GCP 專用伺服器；9 月 3 日發現初始化設定保存 root 密碼，事發前未修正
   官方初步報告時間軸
5. 2026-10-14 01:36
   攻擊者首次使用平台的 AWS 金鑰；01:40 以管理權杖存取共享叢集；13:40 起登入 GCP 專用伺服器
   官方初步報告
6. 2026-10-15 13:56
   收到使用者回報，啟動調查；16:10 至 16:47 攻擊者讀取平台資料庫
   官方初步報告
7. 2026-10-15 21:05
   目前觀察到的攻擊者最後活動
   官方初步報告
8. 2026-10-17
   停止營運公告：12 月 31 日前關閉所有專用伺服器與共享叢集
   官方公告
9. 2026-10-19
   初步報告發布，更正八月報告「已輪替所有內部管理金鑰」的說法
   官方初步報告、狀態頁

怎麼發現

不是平台自己發現的。報告寫明，10 月 14 日持續超過 16 小時的攻擊活動沒有觸發告警，團隊是隔天收到使用者回報才識別事件。

這和八月是同一個形狀：八月也是外部回報金鑰被盜用，平台才知道。報告對這段的解釋是，攻擊者用的是有效憑證、走的是平台的正式存取管道，所以每一筆請求在系統眼中都是合法的。這句話是事實，但也正是問題所在：只會擋「沒有憑證的人」的監控，對「拿著真鑰匙的人」是全盲的。

狀態頁的三次更新也值得看。第一則（10 月 15 日 16:08）只說舊共享叢集上的資料庫遭未授權存取，並寫「目前沒有證據顯示專用伺服器受影響」；4 小時 40 分鐘後的第二則更正為 GCP 專用伺服器也被存取、攻擊者有平台資料庫的讀取權限。範圍在一天內擴大，是調查進行中很常見的事；值得記住的是，第一則通報的範圍不能當成最終範圍。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是該怎麼避免，可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步，下面開始進入技術拆解。

一句話：攻擊者沒有用任何漏洞，全程拿的是平台自己的鑰匙，而這些鑰匙都是長期有效、明文存放的。

報告觀察到攻擊者主要在找能直接用的 API 金鑰，特別是 AI 服務的金鑰：在平台資料庫中搜尋金鑰、大量讀 n8n 與 new-api／one-api 的憑證，也嘗試用平台的 AWS 金鑰呼叫 Amazon Bedrock（全部失敗，沒有產生費用）。10 月 16 日，一位使用者存在平台的 OpenAI 金鑰被用來發出約 1,107 次圖片生成請求，報告推測與這次外洩有關。

攻擊端的入侵指標，報告列了代表性 IP，例如首次使用 AWS 金鑰的 23.106.46.239、以管理權杖存取叢集的 103.237.102.191、9 月初以 root 密碼登入 GCP 的 31.57.201.201。完整清單（含遭植入程式的 PostgreSQL 回連位址）見官方報告；攻擊者大量使用輪替的代理，IP 只能當線索、不能當身分。

這次外洩了什麼

使用者交給平台的東西，和平台自己的鑰匙，這次都在範圍內。

最後一列特別要注意：持有 Hetzner 或 DigitalOcean 的管理權杖，就能重設密碼、重灌系統或複製磁碟，而兩家服務都沒有可用的操作稽核紀錄。這是報告裡「無法確認」最多的一塊。

證據等級

他們怎麼處理

啟動調查後約 4 小時，平台移除了攻擊者的內網節點。當天陸續做的事：管理介面只允許平台系統連線、撤銷並再次輪替管理權杖、停用攻擊者用的兩把 GCP 金鑰、刪除備份存取金鑰、輪替 GitHub App 私鑰與付款服務金鑰、移除初始化設定裡的 root 密碼、停用 24 組 AWS 金鑰並換上權限更小的、輪替登入簽章金鑰讓所有使用者登出、封鎖 GCP 伺服器的公網 SSH、撤銷全部郵件服務金鑰。隔天撤銷 Hetzner 與 DigitalOcean 的權杖。

之後完成的包括：撤銷所有使用者的平台存取權杖、限制只有指定服務能連平台資料庫、叢集備份不再保存明文機密且備份金鑰分開存放。進行中的是追查外洩來源，以及補上報告列出的五類告警：管理權限異常使用、容器內執行指令、大量讀取機密或資料庫、內網加入新節點、雲端金鑰從陌生來源使用。

對使用者的建議很明確：現在就處理，不要等通知信；八月換過的也要再換。 環境變數裡的所有憑證先到供應商撤銷再換新；共享叢集使用者要在資料庫裡面換密碼（只改平台上的環境變數不會改到資料庫）；n8n 要換加密金鑰並重建所有第三方憑證；GCP 專用伺服器當作已遭入侵，備份後重建。帳單回溯到 10 月 14 日，GCP 專用伺服器使用者回溯到 9 月 1 日。第三方服務因此多出的費用，可透過客服申請賠償。

哪裡做對，哪裡做錯

先講做對的。這份報告的寫法，是我們看過的平台事故報告裡最好的幾份之一：精確到分鐘的 UTC 時間、每個主張標確定程度、推測獨立成節並寫出反證（IP 沒有重疊）、主動更正自己上一份報告的錯誤說法、把無法確認的資料一律當作已外洩。另一件做對的事在八月：提供「把環境變數遷到自己伺服器」的指引與一鍵功能。這次證明它有效，照做的使用者避開了平台資料庫這一刀。

做錯的，報告自己列得很完整，我們只挑三件最值得帶走的。

輪替範圍畫錯了。 八月確認外洩的是 GitHub App 私鑰，平台換了私鑰。但這把私鑰能讀整個 GitHub 組織的所有儲存庫，設定儲存庫裡有明文的 AWS 金鑰與管理權杖；私鑰在被讀走後四天才換。只換私鑰，等於換了大門鎖，卻沒換鎖匠可能已經拷貝走的那串備用鑰匙。正確的範圍是：外洩的憑證在有效期間內碰得到的每一個地方，裡面的每一把憑證都要換。

已知的洞排在待辦裡。 root 密碼明文 9 月 3 日就發現，機密遷移 10 月 3 日啟動、事發時還沒合併。報告沒有說為什麼沒在一個月內處理，我們也不猜。但這件事提醒所有團隊：事件後的改善清單，要按「被利用時損失多大」排序，而不是按「改起來多麻煩」。

「唯讀」不等於「安全」。 內部唯讀資料庫帳號能讀所有資料；只需讀單一儲存空間的金鑰，實際能讀整個 AWS 帳號的儲存空間；停用四個月的服務，部署金鑰還有效。攻擊者這次幾乎沒有「寫」任何東西，光靠讀就拿走了一切。

如何避免

平台端的事，使用者只能要求。下面分兩邊寫。

站在平台的位置：第一，管理權杖與雲端金鑰一律有期限，管理介面不對公網；第二，事件後的輪替以「外洩憑證的可達範圍」畫，並把清單公開到使用者能核對的程度；第三，備份不存明文機密，備份金鑰與其他機密分開，否則每一次輪替都會被下一份備份收錄；第四，內部服務與使用者服務不放同一個叢集；第五，偵測要以「拿著真鑰匙的人」為假想敵，容器 exec、大量讀取、陌生來源用雲端金鑰都要告警。這五點報告都已列進改善項目，只是平台已經決定年底停止營運。

站在使用者的位置，這次事件給了一個很少見的對照組：同一個平台、同一次入侵，有把環境變數遷出平台保管的專案，避開了平台資料庫的外洩；沒遷的，被讀走了。 我們三天前寫的「讓每一把密鑰被讀走時都便宜」，這次有了實證。具體做法：

第一，把平台保管的密鑰當成「可能被讀走」的。能從密碼管理器或雲端機密服務在啟動時注入的，就不要長期明文存在平台的環境變數欄位。

第二，加密金鑰不要和被加密的資料放在同一個地方。n8n 這次 607 個中有 602 個把加密金鑰放在環境變數，加密就等於沒有。

第三，事件後的輪替，自己也要用「可達範圍」畫。平台說「確認外洩的請更換」時，你該問的是：存在那裡的還有什麼？

第四，如果你還在這個平台上，搬遷時不要把所有憑證原樣搬過去。換新平台是一次性換掉全部憑證最好的時機，舊的那一批就讓它在舊平台上一起作廢。

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

報告沒有公開任何使用者端的損失金額；能算的是「換掉全部憑證」和「讓下一次便宜」的成本。

合計只加 proven：這次能確認的直接費用是 0 美元，因為報告沒公開任何一筆使用者端的金額。真正的帳在 gap 那一列，以及那 321 萬筆環境變數背後、每一把還沒換的金鑰。

你可以學到什麼

站在攻擊者的位置：他不需要找漏洞，只需要等。上一次事件的輪替清單告訴他哪些鑰匙已經失效，清單以外、同一個抽屜裡的，就是他接下來要試的。

下面五步全部唯讀，做完你會知道自己在這次事件裡還有哪些沒收尾。