TiDB Cloud 資安事件，是 2026 年 10 月公開的一起雲端資料庫服務商遭入侵事件。PingCAP（TiDB Cloud 的開發商）在 10 月 19 日發布官方報告，承認 9 月 9 日到 10 月 7 日之間，有人拿偷來的「服務帳號憑證」進入公司內部系統、複製資料並取得原始碼，將近一個月後才被發現。另一邊，自稱犯案的駭客組織 FulcrumSec 宣稱偷走 10.6 TB 資料，這個數字目前沒有獲得證實。
這起事件在社群上傳得很兇，很多貼文把駭客的說法直接當成事實。這篇用白話把「官方確認了什麼」和「駭客聲稱了什麼」分開講，也整理沒用過 TiDB 的企業，可以從這件事學到哪幾個便宜又有效的防護習慣。
⚠️有在用 TiDB Cloud？先做這三件事
一、更換 TiDB Cloud 的管理 API 金鑰（多家媒體報導 PingCAP 已建議客戶更換）。二、檢查 TiDB Cloud 帳號的成員名單與近期登入、操作紀錄，有不認得的帳號就移除。三、留意 PingCAP 的個別通知信，官方表示確定受影響範圍後會直接通知客戶。官方說明見 PingCAP 安全更新。
TiDB Cloud 資安事件懶人包：官方確認 vs 駭客聲稱
一句話：PingCAP 確認內部系統被入侵、部分管理資料與原始碼被複製，但表示沒有證據顯示客戶存在資料庫裡的資料受影響；駭客宣稱的規模大得多，還在等獨立查證。
項目 | PingCAP 官方確認 | 駭客組織聲稱（未證實） |
|---|---|---|
入侵期間 | 2026 年 9 月 9 日到 10 月 7 日，10 月 7 日發現 | 近兩個月內持續竊取，沒有觸發任何告警 |
怎麼進來的 | 使用偷來的服務帳號憑證 | 用公司程式碼庫裡留著的雲端服務金鑰 |
被拿走什麼 | 使用者名稱與電子郵件、組織與專案關聯、SQL 編輯器內容、合約與計費設定、加密過的 API 金鑰資料表、原始碼 | 總計 10.6 TB、約 490 萬個檔案，首批公開 200 GB；聲稱含 413 個私有程式碼庫、CRM 聯絡人與計費資料 |
客戶資料庫 | 沒有證據顯示存在 TiDB 裡的資料受影響 | 聲稱取得 18 萬個客戶組織紀錄、11.5 萬組 API 金鑰 |
API 金鑰 | 資料表是加密的；外部鑑識公司測試的樣本無法直接當金鑰使用 | 聲稱是明文，其中 4.26 萬組仍然有效 |
上表官方欄整理自 PingCAP 官方報告，駭客欄整理自 The Cyber Security Guru 的整理 與 ChainCatcher 報導。社群上流傳的「每 6 小時導出一次、連續 88 輪」「2022 年就有工單指出任何角色都能重置所有叢集的 root 密碼」等細節，同樣出自駭客公布的資料，真實性還沒有獲得 PingCAP 或第三方確認。
日期 | 發生什麼事 |
|---|---|
9 月 9 日 | 官方認定的入侵起點 |
10 月 7 日 | PingCAP 發現異常，當天停用大部分受影響的帳號 |
10 月 10 日 | 刪除更多憑證、移除過大的跨專案權限，加開儲存空間的紀錄 |
10 月 12 日到 14 日 | 外部鑑識公司回報 4 個漏洞，14 日前全部修補並複測，已知外洩憑證全部失效 |
10 月 19 日 | PingCAP 發布官方報告；駭客組織同期公開聲稱 10.6 TB |
10 月 20 日 | PingCAP 中國區表示未發現中國區客戶的生產資料庫受影響；被點名的 Bitget 也出面說明 |
先搞懂：TiDB Cloud 是什麼、為什麼這次大家這麼緊張
一句話：TiDB Cloud 是「託管資料庫」，企業把資料庫交給 PingCAP 代管，所以服務商自己的系統被入侵，會讓所有客戶都捏一把冷汗。
用銀行保險箱比喻最好懂。自己架資料庫，像是把貴重物品放在自家保險箱，要自己顧鎖、顧監視器。用託管資料庫，像是把保險箱租在銀行金庫，鎖跟保全都交給銀行。這次的狀況是：小偷拿到了銀行內部的門禁卡，進了銀行的辦公區，翻走了客戶名冊、合約與帳單。官方目前的說法是，小偷沒有打開客戶的保險箱；但只要名冊被翻過，客戶自然會擔心下一步。
名詞 | 生活比喻 | 在這次事件的角色 |
|---|---|---|
託管資料庫 | 租在銀行金庫的保險箱 | TiDB Cloud 本身，客戶資料存在這裡 |
管理後台（control plane） | 銀行的櫃台與辦公區 | 記錄誰是客戶、開了哪些資料庫、怎麼收費，這次被翻的主要是這一層 |
服務帳號憑證 | 給機器用的萬用門禁卡 | 攻擊者拿來進入內部系統的鑰匙 |
API 金鑰 | 讓程式代替你操作帳號的遙控器 | 官方說存的是加密版本，駭客說是明文，雙方說法衝突 |
TiDB 是開源的分散式資料庫，在電商、遊戲、金融科技業有不少用戶。這也是為什麼駭客公布的「客戶名單」特別吸睛。被點名的加密貨幣交易所 Bitget 已出面說明，它只在 TiDB Cloud 放公開的成交紀錄，而且兩個多月前就停用了，沒有用戶資料或密碼外洩（見 Crypto Briefing 報導）。被點名不等於資料真的外洩，要看各家後續說明。
攻擊怎麼發生：一張遺落的門禁卡
一句話：攻擊者沒有破解什麼高深的漏洞，他拿到的是一組本來就能合法進門的憑證。
「服務帳號」是給程式和自動化流程用的帳號，例如每天自動備份、自動部署的腳本，都需要一組帳密才能去存取雲端資源。這組帳密通常權限很大，而且不會像人一樣用手機做二次驗證。PingCAP 的報告沒有說明憑證是怎麼被偷的；駭客則宣稱，這些雲端服務金鑰就留在公司自己的程式碼庫裡。
把金鑰寫進程式碼是非常常見的錯誤。工程師為了方便測試，把金鑰直接寫在設定檔，順手一起存進程式碼庫，之後可能換了好幾個人、好幾年都沒人發現。只要程式碼庫被任何一個人看到，金鑰就等於外洩。這跟我們之前拆解過的 部署平台 API 金鑰外洩事件 是同一類問題。
從官方報告的修補動作也看得出問題在哪：10 月 10 日「移除過大的跨專案權限」「加開儲存空間的紀錄」。換句話說，原本一張門禁卡能開的門太多，而且有些門被打開時沒有留下紀錄。
最該記住的一課：被偷可以止血，沒人發現才致命
一句話：任何公司都可能掉鑰匙，真正拉開差距的是「多快發現」。這次從入侵到發現將近四週，資料被複製的時間有多長，損失就有多大。
我們的看法是，中小企業在資安上最容易省掉的就是「監控與告警」，因為它平常看不到效果。大家願意花錢買防火牆、做弱點掃描，卻很少人設定「半夜有大量資料被下載時，傳一則訊息給我」。可是這次事件說明，門再堅固，有人拿到鑰匙就能大方走進來，這時候唯一能救你的就是有人注意到異常。
防護層 | 作用 | 這次事件的啟示 |
|---|---|---|
不把金鑰放進程式碼 | 讓鑰匙不容易掉 | 金鑰放在專門的機密管理工具或部署平台的環境變數 |
最小權限 | 掉了鑰匙也只能開一扇門 | 一個服務帳號只給它工作需要的權限，不要跨專案 |
定期更換金鑰 | 就算掉了，過一段時間也失效 | 設定到期日，離職、外包結案時一定換 |
存取紀錄 | 事後查得出誰做了什麼 | 雲端服務的稽核紀錄要打開並保存 |
異常告警 | 事發當下就有人知道 | 大量下載、陌生地點登入、半夜操作要通知負責人 |
想更進一步，可以讓程式完全不用固定的金鑰，改用短效的臨時憑證，做法見 Workload Identity Federation 是什麼。整體的觀念是 零信任：預設不相信任何一張門禁卡，每次存取都要驗證。
客戶到底有沒有受影響？目前能確定的事
一句話：管理層的資料（帳號、電子郵件、計費、SQL 編輯器裡打過的內容）官方承認被存取；存在資料庫裡的業務資料，官方說目前沒有證據受影響。
要特別注意「SQL 編輯器的內容」這一項。很多人會在網頁版的 SQL 編輯器裡直接查資料、測試語法，打過的查詢語句、甚至查詢中帶到的客戶資料片段，都可能留在紀錄裡。如果你曾經在編輯器裡貼過密碼或個資，最好當作已經外洩處理。
你的情況 | 建議動作 | 急迫程度 |
|---|---|---|
正在使用 TiDB Cloud | 更換管理 API 金鑰、資料庫密碼；檢查成員與操作紀錄；等候官方通知 | 高，今天就做 |
曾經用過、已經停用 | 確認帳號已刪除、相關金鑰已作廢；資料庫若還在就備份後刪除 | 中 |
曾在 SQL 編輯器貼過密碼或個資 | 更換相關密碼；評估是否需要依個資法通報 | 高 |
沒用過 TiDB | 不受直接影響，但可以用下一段的清單檢查自家系統 | 低，但值得做 |
還在調查中的部分包括：哪些客戶受影響、外洩的 API 金鑰是否還能使用、修補前那 4 個漏洞有沒有被利用過。PingCAP 表示確定個別客戶的影響範圍後會直接通知。日本分公司另外發布公告，提到日本地區的個人資料最多約 5 萬筆，相關細節以 PingCAP 官方頁面 的更新為準。
沒用 TiDB 的企業，也該做的 5 件自查
一句話：這次的入侵手法放到任何公司都成立，下面五件事大多不用花錢，請負責系統的工程師或廠商回答就好。
要問的問題 | 為什麼 | 答案應該長怎樣 |
|---|---|---|
我們的程式碼庫裡有沒有金鑰或密碼？ | 這是最常見的外洩源頭 | 有工具定期掃描，金鑰都放在機密管理工具或環境變數 |
每組金鑰是誰在用、權限多大？ | 權限越大，掉了損失越大 | 列得出清單，每組只給工作需要的權限 |
上次更換金鑰是什麼時候？ | 長期不換的金鑰最危險 | 有固定週期，人員異動時一定換 |
雲端服務的存取紀錄有開嗎？保存多久？ | 出事時才查得到 | 有開，至少保存 90 天 |
大量下載或半夜登入，誰會收到通知？ | 決定你多快發現 | 有指定負責人，訊息會即時送到手機 |
人員離職、外包結案時的權限回收，可以參考 離職員工權限回收 SOP；金鑰要放哪裡、工具怎麼選，企業機密管理採購指南 比較了幾種做法。第三方服務商出事時的應變，也可以對照 EVERY8D 簡訊平台遭駭事件 與 npm 供應鏈攻擊 兩篇。想定期請人檢查系統，弱點掃描、滲透測試、壓力測試差在哪 說明了三種檢測的差別；資安責任怎麼寫進外包合約，則可以參考 維護合約範本。
看到這裡，如果你也在想「我們的系統金鑰到底放在哪、出事多久會知道」，我們很樂意 聽你聊聊現在的系統狀況，一起看看哪些該先處理。
ℹ️我們怎麼看
這次事件讓人不安的地方，在於受害者本身就是做資料庫的公司。專業如此，還是會掉在「金鑰沒管好、異常沒人發現」這種最基本的地方，代表這兩件事靠工程師自律做不到，要靠制度和工具。我們的判斷是，未來企業挑選雲端服務商時，「出事多久會發現、多久會通知客戶」會跟價格、效能一樣重要。給老闆的判斷工具：問負責系統的人兩個問題，「我們的金鑰放在哪裡？」「如果有人半夜把資料庫整個下載走，誰會知道？」兩題都答得出來，就有人在顧。
ℹ️我們做過這件事
我們累積了 40+ 企業客製案落地，系統交付時會一起規劃金鑰的存放位置、權限範圍與異常通知，維運期間也會在重大資安事件公告後盡快盤點受影響的範圍。看到這裡，如果你也在想「我們的系統會不會有同樣的破口」，我們很樂意 聽你聊聊現在的實際情況，一起看看從哪一塊開始最划算。
QTiDB Cloud 資安事件是什麼？
TiDB Cloud 是 PingCAP 的託管資料庫服務。PingCAP 在 2026 年 10 月 19 日承認，9 月 9 日到 10 月 7 日之間有人用偷來的服務帳號憑證進入內部系統，複製了使用者、計費、合約等管理資料與原始碼。駭客組織 FulcrumSec 宣稱偷走 10.6 TB，這個數字目前未獲證實。
Q我的資料庫資料有被偷嗎？
PingCAP 表示，目前沒有證據顯示存在 TiDB 資料庫裡的客戶資料受影響，被存取的是帳號、電子郵件、計費、SQL 編輯器內容等管理層資料。官方會在確認個別客戶影響後直接通知，建議先更換管理 API 金鑰與資料庫密碼。
Q駭客說的 10.6 TB、11.5 萬組 API 金鑰是真的嗎？
目前沒有獲得證實。駭客聲稱 API 金鑰是明文且 4.26 萬組仍有效，PingCAP 則說外洩的是加密過的金鑰資料表，外部鑑識公司測試的樣本無法直接當金鑰使用。雙方說法衝突，要等後續獨立查證。
QTiDB Cloud 的用戶現在該做什麼？
建議今天就更換 TiDB Cloud 管理 API 金鑰與資料庫密碼，檢查帳號成員與近期操作紀錄，移除不認得的帳號。如果曾在網頁 SQL 編輯器貼過密碼或個資，也要一併更換或評估通報，並留意 PingCAP 的個別通知。
Q沒用 TiDB 的公司需要擔心嗎？
不受直接影響，但這次的手法在任何公司都可能發生：金鑰寫進程式碼庫、服務帳號權限太大、沒有異常告警。建議檢查程式碼庫有沒有金鑰、每組金鑰的權限、多久更換一次，以及大量下載時有沒有人會收到通知。
Q服務帳號憑證是什麼？為什麼這麼危險？
服務帳號是給程式和自動化流程用的帳號，就像給機器用的萬用門禁卡。它通常權限很大，也不會做手機二次驗證，一旦外流，攻擊者就能用合法身分進入系統，很難被當成入侵。所以要限制權限、定期更換，並開啟存取紀錄與告警。
AUTHOR
恆遠數位編輯團隊
留言(0)
尚無留言，成為第一個留言的人吧！