PingCAP 内部系统遭入侵（TiDB Cloud）

结论复制锚点链接

PingCAP 确认其内部系统遭未授权访问，数据和源代码被复制。[1]攻击者使用了失窃的服务账号凭据。[1]日本官网确认，日本国内最多约 5 万件个人信息泄漏。[9]官方未发现存入 TiDB 的数据受影响，也未确认信用卡信息流出。[1] [9]PingCAP 建议所有客户立即轮换 API 密钥，并警惕定向钓鱼。[8]官方资料未将 NewDB 列为产品或品牌。[2] [3]

事件经过复制锚点链接

PingCAP 于 2026-10-19 发布英文事故报告。[1]2026-10-20，PingCAP 发布客户处置指引。[8]PingCAP 日本官网另发道歉公告，给出了日本的个人信息数量。[9]日本公告注明，文中日期均按美国时间计算。[9]

攻击者在 2026-09-09 至 10-07 访问内部系统。[1] [9]PingCAP 在 10-07 发现事件，当天开始作废凭据。[1] [9]截至 10-14，已识别的失窃凭据全部作废，入侵路径已封堵。[1]

外部响应团队审查了 PingCAP 的生产系统。[1]该团队未发现攻击者执行命令或持续驻留的证据。[1]这一结论不排除已发生的数据暴露。[1]PingCAP 已向执法机关报案，并向各国监管机构报告。[9]

官方确认的暴露涉及 TiDB Cloud 控制面资料和业务资料。[1]它不等同于 TiDB 数据平面被拖库。[1] [9]PingCAP 仍在逐个客户确认实际范围，确认后会直接通知。[1]

NewDB 不是已找到的正式产品名。[2] [3]官方名称是 TiDB Cloud、TiDB Cloud Starter 等。[3]官方还列出 Essential、Premium、Dedicated 与 BYOC。[3]TiDB X 是官方资料中的内核名称。[2]因此，段子中的 TiDB NewDB 应属调侃或误称。

技术细节复制锚点链接

根因是失窃的服务账号凭据被滥用。[1]官方未说明这些凭据如何失窃。[1]FulcrumSec 称，凭据是 PingCAP 代码仓库里的 GCP 和 Azure 凭据。[10]该团体称，它用这些凭据建立了控制面数据库的复制通道。[10]这些说法未经 PingCAP 证实。[1]

官方确认，导出的记录包括以下内容。并非每个客户都涉及全部类别。[1] [9]

• 用户名、邮箱，以及组织、项目和集群标识符。[1] [9]
• SQL 编辑器的执行历史和错误信息。[1] [9]
• 客户联系人的姓名、邮箱、公司名和电话。[9]
• 合同条款、订单、价格、付款条件和账单配置。[1] [9]
• 一张含加密 TiDB Cloud API 键值的表。[1]

API 密钥是双方说法冲突最大的地方。英文公告称，导出的表含加密的 API 键值。[1]日本公告更具体：只泄漏了 Public Key 部分，且该部分已加密。[9]日本公告称 Private Key 未泄漏，仅凭 Public Key 无法操作 TiDB Cloud。[9]PingCAP 称，至今未发现任何键值被解密或使用。[8]FulcrumSec 则称取得 115,308 个明文密钥对，其中 42,612 个有效。[4] [10]

外部团队在 2026-10-12 至 13 报告四项漏洞。[1]PingCAP 在 2026-10-14 前修复了四项漏洞，外部团队已复测。[1]公告未公开漏洞机制、编号或产品版本。[1]公告也未将四项漏洞归因为初始入口。[1]

FulcrumSec 公布了一张据称创建于 2022 年的 Jira 安全工单。[10]工单称，低权限角色可能重置集群 root 密码。[10]工单真伪、修复状态和它与本次入侵的关系都未证实。[10]

影响范围复制锚点链接

目前唯一的官方数字是：日本国内最多约 5 万件个人信息。[9]PingCAP 未公布全球受影响客户、用户或集群的数量。[1]官方称未发现存入 TiDB 的数据受影响。[1]日本公告称未确认对 TiDB Cloud 的未授权访问。[9]

攻击者的说法（未验证）复制锚点链接

FulcrumSec 是一个较新的勒索团体。[7]它声称窃取约 490 万个文件，共 10.6 TB。[4] [10]下表的数字都来自该团体的单方披露。[4] [10]

该团体还称持有 Jira 工单、CRM、分析数据和云成本数据。[7] [13]它称持有 4 年的客户连接日志，含客户应用服务器的 IP。[7] [13]它点名了 Airbnb、Booking.com、百度、富士通、Capcom、Konami 和 Square Enix。[7]它称近 2,000 家受影响组织在日本、中国大陆和香港，约 500 家在印度。[7]PingCAP 和 Dark Reading 都未证实这些说法。[1] [7]

FulcrumSec 有一定的可信记录。[7]该团体曾称从曼彻斯特机场集团窃取 86 GB 数据。[7]后来的报道显示，其中的个人信息比该集团承认的多。[7]该团体后来说，86 GB 是压缩后的大小，解压后为 640 GB。[7]SOCRadar 和 BreachSense 也记录了本次泄漏主张，但它们不是独立取证。[5] [6]

下游客户的回应复制锚点链接

Bitget 的谢家印在 2026-10-20 发文回应。[12]他称 Bitget 只在 TiDB 存过部分公共成交日志，两个多月前已停用。[12]他称没有用户数据或密码泄漏。[12]这是 Bitget 的自述，本报告未验证。Dark Reading 称，PingCAP 官网列出的客户包括 Atlassian、Square、Pinterest、Manus 和 Kimi。[7]被列为客户不等于其数据已泄漏。

为什么控制面数据也危险复制锚点链接

Dark Reading 认为，最大的风险在不起眼的数据里，例如 SQL 历史和工单。[7]Sysdig 的 Crystal Morin 指出，有人调试时会把连接串粘贴进 SQL 编辑器。[7]因此，查询历史和错误输出会变成机密的存放处。[7]FulcrumSec 展示的 SQL 语句中，含一家医疗诊所的病人名单。[7]导出的联系人和账单资料还会让钓鱼邮件看起来更可信。[8]

时间线复制锚点链接

1. 2026-09-08 至 09-30，时区未披露
   FulcrumSec 称每 6 小时导出一次控制面数据，共 88 次。[4][10]
2. 2026-09-09 至 10-07，美国时间
   官方确认攻击者访问内部系统。[1][9]
3. 2026-09-30 06:02 UTC
   FulcrumSec 称最后一次导出完成。[4]
4. 2026-10-07，美国时间
   PingCAP 发现事件并开始作废凭据。[1][9]
5. 2026-10-10，时区未披露
   PingCAP 删除更多凭据，移除跨项目的过量权限。[1]
6. 2026-10-10，时区未披露
   PingCAP 在受影响项目启用存储访问日志。[1]
7. 2026-10-12 至 10-13，时区未披露
   外部团队报告四项漏洞。[1]
8. 2026-10-14，时区未披露
   已识别凭据全部作废，四项漏洞修复。[1]
9. 2026-10-19，时区未披露
   PingCAP 发布英文事故报告。[1]
10. 2026-10-19，时区未披露
    SOCRadar 观察到泄漏站条目。[5]
11. 2026-10-20，时区未披露
    PingCAP 发布客户处置指引。[8]
12. 2026-10-20，时区未披露
    BreachSense 记录该泄漏主张。[6]
13. 2026-10-20 12:07 UTC
    Bitget 的谢家印称 Bitget 没有用户数据泄漏。[12]
14. 2026-10-21 12:18 UTC+8
    InfoQ 汇总官方和攻击者的说法。[10]
15. 2026-10-21 06:13 UTC
    Hackmanac 转述日本官网公告，日本最多约 5 万件个人信息。[11][9]
16. 2026-10-21，时区未披露
    Dark Reading 发表分析文章。[7]

修复与缓解复制锚点链接

PingCAP 已撤销失窃凭据，并封堵已识别的入侵路径。[1]PingCAP 已轮换泄漏的密钥和自己管理的重要密钥。[9]PingCAP 已收紧账号权限，复查网络管理，并加入新的威胁检测。[9]PingCAP 已修复并复测四项漏洞。[1]公告未要求客户升级任何 TiDB 版本，因此没有客户端补丁。[1]

PingCAP 建议客户不等通知，现在就做以下操作。[8] [9]

1. 组织 Owner 轮换所有活跃的 TiDB Cloud 管理 API 密钥。先建新密钥，更新并验证依赖的应用，再删除旧密钥。每个组织都要做一遍。[8]
2. 如果怀疑某个密钥被滥用，先立即吊销，再联系 security@pingcap.com。[8]
3. 检查 TiDB Cloud 和相关云账号的访问日志，找可疑 IP 和陌生操作。[9]
4. 复查组织成员和角色，删除不需要的账号。[9]
5. 警惕定向钓鱼。PingCAP 不会用邮件索要密码或访问密钥。[8] [9]

日本客户的联系窗口是 security-jp@pingcap.com。[9]本报告另外建议轮换曾粘贴进 SQL 编辑器的机密。客户还应检查 2026-09-09 至 10-07 的异常 API 调用和新建的访问主体。客户不应下载或处理泄漏站上的数据。

对段子中公司的影响复制锚点链接

如果该公司买的是 TiDB Cloud，这次风险直接相关。其员工邮箱、电话和组织关系可能已被导出。[1] [9]其 SQL 编辑器里的查询和报错可能已暴露。[1]查询里粘贴过的连接串或机密风险最高。[7]其合同、价格和账单配置也可能受影响。[1]

该公司应把 TiDB Cloud API 密钥当作待轮换凭据，今天就换。[8]该公司还应轮换出现在编辑器中的下游密码。财务和运维团队要警惕“修改付款信息”一类的钓鱼邮件。[8]如果该公司有日本业务，还要关注 PingCAP 日本的个人信息通知。[9]

如果该公司只部署自管 TiDB，目前没有证据显示它受影响。官方未发现 TiDB 内存储的数据受影响。[1]自管部署不在 TiDB Cloud 控制面的范围内。购买价格不会改变这次的暴露机制。

存疑与未验证复制锚点链接

未找到 NewDB 是 PingCAP 正式产品的证据。[2] [3]未找到 CVE、GHSA、CVSS 或修复版本的公开记录。[1]未找到全球受影响客户数或数据主体数的官方数字。[1]日本的“最多约 5 万件”是唯一的官方数量。[9]未找到存入 TiDB 的数据被窃的官方证据。[1]未找到四项漏洞与初始访问之间的因果证据。[1]

英文公告说“加密的 API 键值”，日本公告说“仅 Public Key 部分”。[1] [9]两份公告的措辞不同，本报告以更具体的日本公告为准。FulcrumSec 的明文密钥说法与两份公告都冲突。[4] [10]FulcrumSec 的 10.6 TB、客户名单和 Jira 工单都只是主张。[4] [7] [10]Bitget 称未泄漏用户数据，这是企业自述。[12]官方调查仍未结束，后续通知可能改变结论。[1]

参考资料复制锚点链接

• [1] Security Incident Report: Unauthorized Access to PingCAP
• [2] TiDB Cloud Release Notes in 2026
• [3] The Easiest Way to Run TiDB at Scale
• [4] THE PingCAP / TiDB Cloud LEAKS
• [5] PingCAP / TiDB Cloud Data Breach
• [6] PingCAP
• [7] TiDB Breach Exposes Flawed Cloud Security Assumptions
• [8] Security Incident: Recommended Customer Actions
• [9] 不正アクセスによる情報漏洩に関するお詫びとご報告
• [10] PingCAP 遭大规模数据泄露！黑客声称窃取 10.6TB 数据（InfoQ）
• [11] Hackmanac: PingCAP confirmed a data breach affecting up to 50,000 personal records in Japan
• [12] 谢家印（Bitget）关于 TiDB Cloud 泄漏的回应
• [13] Hacker News: PingCap TiDB Leaks