先说结论：这次被攻破的不是 TiDB 数据库，而是卖数据库的 PingCAP 公司。

攻击者拿着偷来的服务账号凭证，在 PingCAP 的内部系统里进出了 28 天，拷走了客户数据和源代码。客户集群里存的数据，官方说没有证据表明受影响。但厂商手里攒的东西——你在控制台里写过的 SQL、你的合同价格、你的工单——丢了一大批。

对 DBA 来说，这件事真正值得琢磨的问题是：把数据库托管出去之后，信任边界到底画在哪。

PingCAP 事件概念图

一、事件速览

项目 内容
事件性质 厂商内部系统入侵（非 TiDB 产品漏洞）
入侵窗口 2026 年 9 月 9 日至 10 月 7 日（美国时间），共 28 天
入口 被盗的服务账号凭证
发现时间 10 月 7 日，PingCAP 当天开始禁用受影响凭证
官方确认被拷走 账户信息、SQL 编辑器文本与错误信息、合同订单与账单信息、加密的 API 密钥值，以及源代码
未发现受影响 TiDB 中存储的数据；攻击者在生产系统执行命令或驻留的证据
日本版披露 日本国内最大约 5 万件个人信息泄露
攻击者声称 FulcrumSec 声称窃取约 10.6 TB 并放出样本（未经证实）
客户要做的事 轮换管理 API 密钥、查访问日志、防定向钓鱼

二、时间线

  • 9 月 9 日：入侵窗口开始。攻击者开始使用被盗的服务账号凭证访问 PingCAP 内部系统。
  • 10 月 7 日：PingCAP 发现事件，当天着手禁用受影响凭证。
  • 10 月 10 日：删除更多被攻陷凭证，去除云项目之间的过量权限；在一个受影响项目上开启额外的云存储访问日志。
  • 10 月 12 至 13 日：外部调查公司向 PingCAP 报告了 4 个漏洞。
  • 10 月 14 日：4 个漏洞全部修复并经复测确认；所有已识别的未授权访问路径封堵完毕。
  • 10 月 19 日：英文版事件报告发布。
  • 10 月 20 日：英文版客户行动指南发布；平凯数据库发布中文版公告。
  • 10 月 21 日 13:05：日本版公告追记，受影响数据新增「支持工单信息」一项。

有一个细节值得多看一眼：官方对入口的定性是「被盗凭证」，但在调查期间又修复了 4 个漏洞，并且明确写了还在核查「这些漏洞在修复之前是否被利用过」。也就是说，「纯凭证入侵」这个结论，官方自己也没有完全说满。

三、到底丢了什么：为什么 SQL 编辑记录最扎眼

按英文版官方报告，已确认被导出的数据分三类，外加一项单独的东西。

第一类，账户与产品使用数据。 用户名、电子邮件地址、组织与项目的关联关系，以及 SQL 编辑器里执行过的文本和错误信息，部分记录还包含组织、项目和集群的 ID。

这一类最扎眼的就是 SQL 编辑记录。云控制台里的 SQL 编辑器，是 DBA 随手跑查询、试语句、排问题的地方。里面出现过的东西，可能包括表结构、业务字段名、真实的查询条件、调试时粘进去的样例值。一条 SQL 泄露出去，丢的不是某一行数据，而是你家数据库的地图和业务的形状。错误信息更甚：表名、列名、约束细节都在报错里躺着。

第二类，商业与账单信息。 客户联系人、合同条款、订单、定价、付款条款、账单配置。

这类数据的危害不在当下，在后续。拿着你的真实联系人、真实合同和真实账单信息，钓鱼邮件可以写得和真的一样。PingCAP 的客户行动指南专门用一节讲这件事：凡是索要密码或验证码的、要求变更付款信息的、催促你紧急处理账户的，先停一下，走之前就用惯的渠道回去核实。

第三类，凭证。 一张被导出的表里含有 TiDB Cloud API 密钥的值，但官方强调是加密的：外部调查公司拿一个调查员自有的值做过测试，无法直接当作 API 密钥使用。日本版公告的口径更细一层：泄露的是 API 密钥的公钥部分，私钥部分没有泄露，且公钥部分本身经过加密。

攻击者声称自己手里有明文密钥。官方对此的标注只有四个字：未经证实。

外加一项：源代码被获取。 这不是当下的数据泄露，而是未来的风险存量。拿到源码的人可以离线慢慢读、慢慢找洞。这件事的长尾，会比那 28 天长得多。

被拷走的数据类别

四、三个版本，三种口径

同一件事，PingCAP 前后发了三个版本，详细程度差得很远。这是这起事件里最有意思的部分。

英文版（10 月 19 日）最完整。 入侵窗口、入口方式、源代码、SQL 编辑器、4 个漏洞的修复，都写了；确认的事实和待确定的事项还分开列表，写明「调查仍在进行」。

日文版（PingCAP 日本公司）按日本《个人信息保护法》的要求披露，给出了「日本国内最大约 5 万件个人信息泄露」这个具体数字，和一份完整的受影响数据表。10 月 21 日还追记了一笔：受影响数据里新增支持工单信息。日本用户还直接收到了邮件通知：10 月 20 日一封事件报告与致歉，10 月 21 日又追加一封，点名请 TiDB Cloud 账户持有人尽快轮换 API 密钥。

中文版（平凯数据库，10 月 20 日）最简。 全文只说「公司部分内部经营数据被未经授权访问并泄露」，受影响信息只列了两类：部分销售线索及订单记录（并注明其中部分内容为公开招投标信息）、部分需求单信息（并注明是数据库需求的通用性技术描述，例如 SQL 优化器改进等）。没有提源代码，没有提 SQL 编辑器，没有提 API 密钥，也没有提入侵窗口。

给读者留一个实用提示：看跨国厂商的安全公告，别只看你所在语言的那一版。 披露的详细程度往往由当地法规决定，不是由事件本身决定。想看全貌，去找监管最严的那个法域的版本。

五、攻击者那边的说法

声称对这起事件负责的，是一个叫 FulcrumSec 的勒索与披露组织，此前它还点过 LexisNexis、诺和诺德、曼彻斯特机场集团等机构。

它的说法是：从 TiDB Cloud 持续窃取了约 10.6 TB 数据，并已放出约 200 GB 的第一批样本，还声称持有明文 API 密钥。Dark Reading 的报道则称，攻击者一度对 PingCAP 的云管理、财务、分析、存储等系统拥有近乎不受限的访问，长达近一个月。

这些说法目前都没有得到官方证实。其中「明文 API 密钥」一条，与官方「导出的是加密值、实测无法直接使用」的调查结论直接冲突。不过，样本并非空穴来风：已经有第三方研究者对攻击者放出的样本展开分析，样本中包含成规模的内部数据表。具体到每一个客户究竟丢了什么，官方说还在逐户确认，完成之后会直接通知受影响的客户。

客户一侧倒是有个公开回应值得一提：加密货币交易所 Bitget 表示，它只在 TiDB Cloud 上存过公开数据，而且两个多月前就已经停用了这项服务。

六、如果你在用 TiDB Cloud，现在就做这四件事

这是 PingCAP 官方行动指南和日本版公告里给客户的要求，合并成一张清单：

客户处置清单

  1. 轮换管理 API 密钥。 只有组织 Owner 能建、能删。顺序别做反：先创建新密钥，把应用、脚本和自动化全部切换过去并验证正常，再删除旧密钥。已经怀疑某个密钥被滥用的，先吊销、再联系 security@pingcap.com，哪怕集成会短暂中断也别等。
  2. 查访问日志。 TiDB Cloud 以及关联云账号的访问日志过一遍，看有没有陌生 IP 和不认识的操作记录。
  3. 清一遍组织成员和角色。 删掉不再需要的账号，把过大权限收回来。
  4. 防定向钓鱼。 泄露数据里有你的真实联系人和账单信息，接下来几个月，所有涉及密码、验证码、付款变更的「官方邮件」，默认先怀疑。

七、这件事留给 DBA 的三个问题

第一，托管数据库的信任边界，不在你的数据平面，在厂商的运营平面。 你把数据库交给云厂商的那一刻，一起交出去的还有你的 SQL 历史、你的工单、你的合同和你的联系人。这些东西躺在厂商的内部系统里，享受的是厂商内部 IT 的安全水平，不是数据库产品本身的安全水平。这次入侵的入口是一个被盗的服务账号凭证，和 TiDB 这个产品写得好不好没有关系。

第二，选托管数据库时，可以多问三句。 控制台的 SQL 编辑历史保存多久、谁能看？工单系统里的数据怎么存放、怎么隔离？厂商内部系统与客户数据平面之间是怎么分开的？这些问题以前很少有人问，这次事件之后，值得写进选型清单。

第三，能不出机房的数据，就别出机房。 像巡检、审计这类工作，完全可以在自己的环境里闭环：工具部署在自己手里，数据留在自己手里，就不存在「厂商被端了连带我一起」的风险。这也是我做 DBCheck 时坚持自托管的原因。

最后说句公道话：PingCAP 的英文版披露，在厂商安全事件里算写得相当细的，时间线、证据、未决事项都分得清清楚楚。中文版写得简，有它的背景：被入侵的是海外 TiDB Cloud 的运营系统，而 TiDB Cloud 本身不在中国大陆运营；国内对应的是今年年初刚上线的平凯数据库云服务（console.cloud.pingkai.cn），平凯目前的重心在企业版及其信创版本上，中文版公告也明确说，此次事件不涉及平凯数据库云服务和企业版产品。问题只是，国内仍然有不少用户在用海外的 TiDB Cloud——对他们来说，能拿到的官方中文说明，就只有这份最简版。

参考来源

原文作者: liups.com

原文链接: http://liups.com/posts/b89363ff/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议