事件背景
PingCAP 是 TiDB 的開發公司。TiDB 是一套開源的分散式 SQL 資料庫，主打與 MySQL 相容，能同時處理線上交易與分析型查詢，並以雲端托管服務 TiDB Cloud 的形式提供給企業客戶。根據 InfoQ 於 2026 年 10 月 25 日由 Renato Losio 撰寫的報導，PingCAP 已確認自家內部系統遭到未授權存取，且原始碼與客戶相關資料被竊。這起事件之所以受到關注，不只是因為資料量可觀，更在於外洩內容集中在雲端服務的管理層，而不是客戶實際存放業務資料的資料庫。
洩漏範圍與雙方說法
發動攻擊的勒贖團體 FulcrumSec 自稱竊得 10.6 TB 資料，內容涵蓋 TiDB Cloud 控制平面（control plane）紀錄、客戶的 SQL 語句、API 金鑰、連線日誌、帳務資訊、內部文件，以及 413 個私有原始碼儲存庫。這些說法目前並未經獨立驗證。FulcrumSec 還聲稱存取行為持續數週未被發現，且部分外洩憑證可能讓攻擊者進一步接觸客戶系統。
PingCAP 的說法相對保守。其事故報告指出，外部事件應變公司檢視過 PingCAP 的生產系統後，並未在受檢視的系統中發現攻擊者執行命令或維持持續存取的證據；在外部律師與第三方鑑識專家協助下，也沒有證據顯示存放於 TiDB 內的資料受到影響。不過 PingCAP 也確認，被匯出的紀錄包含使用者名稱與電子郵件地址、組織與專案關聯，以及 SQL 編輯器中的文字與錯誤訊息，部分紀錄另含組織、專案與叢集識別碼。
攻擊者提出的具體主張
FulcrumSec 進一步宣稱取得了 metadb 的完整副本，內含約 18 萬個租戶組織、近 30 萬筆使用者紀錄，其中約 16.6 萬筆為真實姓名，以及超過 40 萬個不重複的電子郵件地址。該團體也表示握有 11.5 萬組 console API 金鑰對，其中逾 4 萬組仍處於有效狀態，最新的一組據稱是在其宣稱結束存取前數小時才建立。此外，他們聲稱從客戶的遷移工作中取得約 1800 個外部資料庫端點，包含客戶 MySQL 與 Aurora 主機的 root 與 admin 帳號，並指控 PingCAP 工程師曾把客戶的生產環境憑證貼進 Jira 工單，其中三份日誌被完整重現。
這些數字的規模值得注意，但目前僅屬攻擊者單方面陳述。就已公開的內容來看，FulcrumSec 的第一批釋出資料為五個 tar.gz 壓縮檔，壓縮後合計 128.3 GB，解壓後略超過 200 GB，與其聲稱的 10.6 TB 仍有相當落差。
為何控制平面外洩比資料庫本身更敏感
42Sec 創辦人兼總監 Kim Barthel 對這起事件的定性提出提醒：這不完全是資料庫的故事，而是關於一組服務帳號金鑰的故事。PingCAP 表示沒有證據顯示客戶存放在 TiDB 內的資料被動到，這點固然重要，但真正外洩的東西同樣關鍵。持有這些資料的人，會知道企業有哪些工程師、付了多少費用、合約何時續約，以及資料結構長什麼樣子，這些資訊足以拼湊成一封讓人真的會相信的釣魚郵件。
這也點出雲端服務架構中容易被忽略的風險。控制平面負責管理、組態、計費、金鑰與 API 存取，和實際存放業務資料的資料層並不相同。供應商可能在查詢歷史、支援工單與診斷日誌中，不經意地留存客戶的敏感資料；即使客戶自己的資料庫沒有被入侵，這些周邊紀錄仍可能讓客戶暴露在風險之中。
廠商回應與社群質疑
PingCAP 建議客戶更換仍在使用中的 TiDB Cloud 管理 API 金鑰，並對針對性的釣魚攻擊保持警覺。在 Hacker News 的熱門討論串中，實務工作者對 PingCAP 的回應提出不少疑問，其中一點是攻擊者聲稱曾反覆匯出控制平面資料庫，卻在超過一個月的時間內沒有觸發任何偵測。使用者 dherls 直言，若該說法為真，代表 PingCAP 的維運能力出現嚴重問題，攻擊者甚至可能建立了持續一個月的複寫管道。
另一位使用者 xKingfisher 則把矛頭指向時間點，提到 PingCAP 近期才發布名為 TiDB Opens Source Code to Independent Security Review, Strengthens Enterprise Trust Program 的新聞稿，在 NCC 安全稽核之後不久就發生這起事件，對各方而言都相當難堪。這些評論反映出社群對事件揭露節奏與資安治理成熟度的雙重質疑。
影響、實務意義與限制
報導提到，據稱外洩的紀錄包含與 Booking.com、Shopee、Airbnb、Pinterest、Databricks、Atlassian、Fujitsu、SoftBank 與 Baidu 等企業相關的資料，但這並不能證明這些組織已被入侵。例如報告中提到的加密貨幣交易所 Bitget 便表示，其內部調查並未發現使用者資料外洩的證據。
從實務角度來看，這起事件提醒企業在採用托管資料庫服務時，不能只關心自己的資料表是否被讀取，還要追問供應商在支援流程、內部工單與監控日誌中保存了哪些客戶資訊、保存多久、誰能存取。對 PingCAP 而言，後續的鑑識結果、實際外洩範圍，以及攻擊者是否真能藉由外洩憑證橫向移動，才是決定這起事件最終嚴重程度的關鍵。在獨立驗證完成之前，攻擊者對資料規模的宣稱與受害企業名單，都應被視為未經確認的資訊。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。