PingCAP 确认遭未授权访问

PingCAP 是分布式数据库 TiDB 的开发商，托管服务 TiDB Cloud 由它代客户运行集群，账号、账单和支持工单也留在它这一侧。2026 年 10 月 19 日，PingCAP 在 Trust Hub 发布事件报告，确认 9 月 9 日至 10 月 7 日（美国时间）有人用窃取的服务账号凭据进入部分内部系统，复制了数据，并取得源代码；公司在 10 月 7 日发现，当天开始停用受影响的凭据。

要点

处置集中在 10 月 7 日至 14 日：PingCAP 说 10 月 7 日发现后当天开始停用凭据，10 月 10 日追加删除凭据、收回云项目之间多余的权限，并为受影响的项目补开云存储访问日志；外部机构 10 月 12 至 13 日报出四个漏洞，10 月 14 日全部修复并复测通过，同日封堵已识别的未授权访问路径。
确认被导出的记录分三类：TiDB Cloud 账号与产品使用数据（用户名、邮箱、组织与项目关联、SQL 编辑器文本与报错，部分含组织、项目、集群标识），商务与账单数据（客户联系人、合同条款、订单、定价、付款条件、账单配置），以及一张存有加密后 API Key 值的表。
攻击者的规模数字仍是单方声索：FulcrumSec 称拿走 10.6TB、4,901,203 个文件、180,046 条租户组织记录和 115,308 个「明文」API Key，其中 42,612 个称仍有效。PingCAP 未确认规模，只说明调查方持有的一个样本 Key 无法直接当密钥使用。

背景

TiDB Cloud 是托管数据库，客户把业务库放上去，运维交给 PingCAP。这类服务要跑起来，供应商手里必然攒着一批客户侧的东西：账号与组织项目关联、查询历史、工单内容、合同与账单，以及调用 API 的密钥。它们平时散在控制台、Jira、CRM 和财务系统里，单看都不算什么；凑在一起，就是一张能指回具体客户的地图。

这次披露分三波落地。10 月 19 日英文 Trust Hub 出报告；10 月 20 日 Bitget 作出回应；10 月 21 日 PingCAP 日本发布面向日本客户的通知，Dark Reading 同一天刊出独立分析。日本那份通知在 13:05 有一次追记，把支持工单信息补进受影响类别；我们 10 月 22 日读到的英文报告里没有这一项，全文没有出现 ticket 一词。

事实部分

PingCAP 确认的内容与攻击者声索的内容，量级差得很远，写作时不宜混用。

项目	PingCAP 的表述	FulcrumSec 的声索（未获独立核实）
时间窗口	9 月 9 日至 10 月 7 日（美国时间），10 月 7 日发现	9 月 8 日至 9 月 30 日每 6 小时导出一次，共 88 次，最后一次在 9 月 30 日 06:02 UTC
数据量	未公布	10.6TB、4,901,203 个文件；首批 5 个归档压缩后 128.3GB，解压略超 200GB
API Key	导出的表中为加密值；调查方持有的一个样本 Key 无法直接使用；其余可用凭据是否泄露仍在查	115,308 个明文 Key，42,612 个仍有效
客户侧数据	与外部律所、第三方取证机构共同调查，未见 TiDB 中所存数据受影响的证据	约 2,065 万条 SQL 语句、1.02 亿条网关连接、5,036,738 个客户服务器 IP、413 个私有仓库

表里的窗口差异值得单独看一眼。FulcrumSec 说导出管道在 9 月 30 日就关掉了，PingCAP 说未授权访问持续到 10 月 7 日。两者可以同时成立——拿到凭据的入口未必只有那条管道——但目前没有任何一方给出能对上这两段时间的说明。

PingCAP 还写明，外部事件响应机构在被审查的生产系统里没有发现攻击者执行命令或维持持久访问的痕迹，并特意补了一句，这一结论不改变上面列出的数据暴露。两个说法看似矛盾，其实分工不同：一条说的是攻击者在系统里有没有留下后门，另一条说的是已经导出的记录里有什么。读的时候别把前者当成后者。

凭据这一项也有分歧。攻击者称为明文，PingCAP 说导出的表里是加密值，并以一个调查方自有的 Key 做过实测：外部机构拿它直接当 API Key 用，用不了。这个测试只覆盖一个样本，PingCAP 也承认其余可用凭据有没有泄露还没查清。日本通知把范围写得更细：流出的是 API Key 的 Public Key 部分，Private Key 没有流出，只有公钥无法操作 TiDB Cloud，并且公钥部分本身是加密的。

日本那份通知给出的地区数字是「日本国内最多约 5 万件个人信息」，日文原文用的动词是「漏洩」。单位是「件」，通知没有说明这 5 万件对应多少人，标题里的「5 万」按件计更稳妥。它把受影响数据分成账号信息、交易相关信息、认证信息三类，交易类含姓名、邮箱、企业名、电话、订单内容、付款条件和账单设置；通知还说，未确认 TiDB Cloud 本身被未授权访问，也未确认信用卡信息外泄，已向执法机关提交届出并向相关各国监管当局报告。PingCAP 在英文报告里写明，会在确定各客户的具体影响后直接通知受影响客户，但没有公布受影响客户的数量或名单。

各方说法

Dark Reading 在 10 月 21 日的分析（Nate Nelson 署名）明确表示没有独立核实 FulcrumSec 的数字，并称截稿前 PingCAP 未回应其置评请求。它引的两位从业者把风险落在同一个位置：供应商环境里的元数据。

Sysdig 的 Crystal Morin 说，供应商通常不会主动去存密钥，是便利性功能让敏感数据跑到了意料之外的地方——SQL 编辑器的执行记录与报错就是典型，用户调试时把连接串粘进去，密钥就留在了那里。她给采购方的问法很具体：供应商保留哪些客户提供的数据、保留多久、是否在写入时扫描并抹掉密钥、服务账号凭据的寿命与轮换怎么做、泄露通知的触发条件是什么。

Keeper Security 的 Shane Barney 说得更直接：攻击者不必直接攻破客户的主库，只要能系统性地收集上游凭据就够了。客户元数据、API Key 和诊断查询日志会通过日常运维渗进供应商环境，一旦这些凭据被拿走，它们就成了后续利用的路线图。他建议轮换面向供应商的 API Key、清掉硬编码与长期不过期的密钥，并把 SOC 2 Type II、ISO 27001 这类第三方评估作为采购门槛。

客户这一侧目前只有一家公开表态。据 Crypto Briefing 10 月 20 日报道，Bitget 大中华区负责人（报道写作 Xie Jiayin）确认该交易所用过 TiDB Cloud，但只存了公开的成交记录，且两个多月前已停用；内部审查未发现用户数据或密码外泄，也未确认有客户资产或信息被窃。Bitget 把这件事定性为供应商侧的问题，同时提醒用户警惕钓鱼邮件。这是被点名方的自述，没有独立验证。

中文侧，InfoQ 10 月 21 日的报道完整列出了攻击者的数字，并标注「尚未得到独立验证」。在提到 10 月 20 日平凯星辰的说明时，它放了一个指向「中国区情况说明」的链接，然后接冒号写道：「截至目前，未发现中国区客户生产数据库及业务数据受到影响，本事件亦非由 TiDB 内核漏洞导致」。我们打开这个链接指向的 pingkai.cn 页面，标题是「平凯星辰网络安全事件情况说明公告」，落款 2026 年 10 月 20 日，正文里找不到这句话，也没有出现「中国区」「内核漏洞」「生产数据库」这些词。该页实际写的是另一层内容：受影响的是「部分销售线索及订单记录信息」与「部分需求单信息」，并称「此次事件不涉及平凯数据库企业版、平凯数据库云服务等产品的安全漏洞和缺陷，不会对客户数据库系统和业务数据安全造成影响」。

平凯星辰这一页与另外两份说明的口径并不重合。它把受影响数据限定在销售线索、订单记录与需求单，比日本通知列出的账号信息、工单信息、联系人、合同条款与 API Key 公钥部分窄得多；它给出的产品侧结论也比英文报告绝对——英文写的是「没有证据表明存储在 TiDB 中的数据受到影响」，中文写的是「不会对客户数据库系统和业务数据安全造成影响」。同一家公司、三天内、三份表述，跨境客户按哪个实体收到通知，看到的就是哪一版。

日本媒体这边，ビジネス＋IT 的报道在 10 月 21 日 20:55 经 Yahoo 新闻发出，复述了同一份通知里的 5 万件这个数字与三类数据，也照抄了「已向执法机关届出、向各国监管当局报告」这一句。报道本身没有补充新数字，但它说明这份日文通知进入了普通商业媒体的读者群，而不只是发给主动去官网找的客户。

编辑判断

对跑 TiDB Cloud 的团队，这起事件该按凭据事件处置。数据库里的业务数据目前没有证据被拿走；PingCAP 确认导出的是组织与项目关联、SQL 编辑器文本与报错、客户联系人与合同账单配置，以及一张存有加密 API Key 的表。业务数据泄露和账号被接管是两种风险，处置动作也不同。

控制面元数据的危险，Morin 和 Barney 都指着同一个机制：一条写着 mysql://用户:密码@主机 的调试记录，一段贴进工单的备份配置，一枚长期不换的云厂商访问密钥，单独看都是运维痕迹，落到别人手里就是入口。这三样是他们对这类风险的一般描述，不是本次泄露的清单。落到 PingCAP 已确认的类别上，对得上的是 SQL 编辑器的文本与报错——Morin 说的正是这里——以及日本通知追记的「問合せ情報（サポートチケット情報）」，但通知没有说明工单里包含什么，也没有说其中是否有附件或凭据。所以能确认的是「查询历史和工单内容被导出」，不能确认「每条工单里的密钥都被拿走了」。反过来说，如果团队从来没在 SQL 编辑器和支持工单里贴过真实凭据，这起事件的直接风险会低很多——但这需要去翻记录才能确认，不能靠印象。

有两处判断我认为可以下定。第一，检测是这次最大的短板：攻击者声称连续 88 次导出没有被发现，而 PingCAP 自己说 10 月 10 日才为受影响的项目补开云存储访问日志，两条信息指向同一个结论。第二，规模数字在独立取证出来之前不该被引用为事实；10.6TB 这个数字已经在标题里传了一圈，但它来自索要赎金的一方。

还有几件事没有答案。没有公开的取证报告，没有受影响客户的数量与名单，PingCAP 说仍在逐一确认并将直接通知。日本通知与英文报告的覆盖范围不同：前者量化了日本地区的个人信息，后者承认导出了用户名与邮箱却不给数量，两个数字不能互相替代。攻击者点名的一批租户来自泄露样本里的标记，除 Bitget 外没有第二家公开确认，写的时候只能当作「据称出现在样本中的名称」。

现在该做什么

日本通知给客户的四条建议可以直接照做：查 TiDB Cloud 与相关云账号的访问日志，找陌生 IP 和没有印象的操作；复查组织成员与角色，删掉不用的账号、收紧权限；对声称来自 PingCAP 的邮件保持警惕，官方说不会在邮件里索要密码或访问密钥；发过 API Key 的客户轮换密钥。

还可以加一条，针对这次泄露的具体类别：翻一遍 SQL 编辑器的执行历史和提过的支持工单，看有没有把连接串、数据库密码或云厂商密钥贴进去过。有的话，按已泄露处理，改密码、换密钥、查那台主机的登录记录，别等官方通知。同类问题在供应商侧的凭据窃取里反复出现，LiteLLM 1.107.0 那次发布链被植入窃密器也是同一条逻辑：攻击者先拿凭据，再用凭据扩大战果。至于「供应商环境里到底存了多少我的东西」，可以参照这几起 AI 智能体越权事故里反复出现的教训——权限、日志与出口控制，出事时决定损失大小。